प्रोग्रामर र इन्जिनियरहरूको लोककथा (भाग 1)

यो इन्टरनेटबाट कथाहरूको चयन हो कि कसरी बगहरू कहिलेकाहीं पूर्ण रूपमा अविश्वसनीय अभिव्यक्तिहरू हुन्छन्। सायद तपाईलाई पनि केहि भन्नु छ।

भेनिला आइसक्रिममा कारको एलर्जी

ईन्जिनियरहरूका लागि एउटा कथा जसले बुझ्दछन् कि स्पष्ट सधैं जवाफ हुँदैन, र तथ्यहरू जतिसुकै टाढाको जस्तो लाग्न सक्छ, तिनीहरू अझै पनि तथ्यहरू हुन्। जनरल मोटर्स कर्पोरेशनको पोन्टियाक डिभिजनले एउटा गुनासो प्राप्त गर्यो:

यो दोस्रो पटक हो जुन म तपाईंलाई लेख्दै छु, र म तपाईंलाई जवाफ दिनुभएन भनेर दोष दिन्दिन, किनकि यो पागल लाग्छ। हाम्रो परिवारमा हरेक रात डिनर पछि आइसक्रिम खाने चलन छ। आइसक्रिमका प्रकारहरू प्रत्येक पटक परिवर्तन हुन्छन्, र रातको खाना पछि, सम्पूर्ण परिवारले कुन आइसक्रिम किन्ने छनौट गर्दछ, त्यसपछि म पसलमा जान्छु। मैले भर्खरै नयाँ Pontiac किनेको छु र त्यसबेलादेखि आइसक्रिम पाउनको लागि मेरो यात्राहरू समस्या भएको छ। तपाईंले देख्नुहुन्छ, जब म भेनिला आइसक्रिम किन्छु र पसलबाट फर्कन्छु, कार सुरु हुँदैन। यदि मैले अरू कुनै आइसक्रिम ल्याएँ भने, कार कुनै समस्या बिना सुरु हुन्छ। म एउटा गम्भीर प्रश्न सोध्न चाहन्छु, जतिसुकै बेवकूफ लागे पनि: "पोन्टियाकको बारेमा के हो जसले यो भ्यानिला आइसक्रिम ल्याउँदा सुरु गर्दैन, तर अर्को स्वाद आइसक्रिम ल्याउँदा सजिलै सुरु हुन्छ?" "

तपाईले कल्पना गर्न सक्नुहुन्छ, डिभिजन अध्यक्ष पत्रको बारेमा शंकास्पद थिए। तर, मैले जाँच गर्न इन्जिनियर पठाएँ । एउटा सुन्दर इलाकामा बस्ने एक धनी, शिक्षित व्यक्तिले उहाँलाई भेटेकोमा उहाँ छक्क परे। तिनीहरू रातको खाना पछि तुरुन्तै भेट्न सहमत भए ताकि तिनीहरू दुवै आइसक्रिमको लागि पसलमा जान सकून्। त्यो साँझ यो भेनिला थियो, र जब तिनीहरू कारमा फर्किए, यो सुरु हुनेछैन।

इन्जिनियर अझै तीन साँझ आयो। पहिलो पटक आइसक्रिम चकलेट थियो। गाडी स्टार्ट भयो । दोस्रो पटक स्ट्रबेरी आइसक्रिम थियो। गाडी स्टार्ट भयो । तेस्रो साँझ उसले भ्यानिला लिन भन्यो। गाडी स्टार्ट भएन ।

तर्कसंगत तर्क गर्दै, इन्जिनियरले कारलाई भेनिला आइसक्रिमबाट एलर्जी थियो भनेर विश्वास गर्न अस्वीकार गरे। त्यसकारण, मैले कार मालिकसँग सहमति जनाएँ कि उनले समस्याको समाधान नपाएसम्म आफ्नो भ्रमण जारी राख्नेछन्। र बाटोमा, उसले नोटहरू लिन थाल्यो: उसले सबै जानकारीहरू लेख्यो, दिनको समय, पेट्रोलको प्रकार, पसलबाट आगमन र फिर्ताको समय, आदि।

इन्जिनियरले चाँडै थाहा पाए कि कारको मालिकले भेनिला आइसक्रिम किन्न कम समय बिताए। कारण पसलमा सामानको लेआउट थियो। भेनिला आइसक्रिम सबैभन्दा लोकप्रिय थियो र यसलाई सजिलै पत्ता लगाउन पसलको अगाडि छुट्टै फ्रिजरमा राखिएको थियो। र अन्य सबै किस्महरू पसलको पछाडि थिए, र यसले सही विविधता र भुक्तान गर्न धेरै समय लियो।

अब प्रश्न इन्जिनियरको थियो– इन्जिन बन्द भएको समयभन्दा कम समय बितिसकेको भए कार किन स्टार्ट भएन ? समस्या समय थियो र वेनिला आइसक्रीम थिएन, इन्जिनियरले चाँडै जवाफ फेला पार्यो: यो एक ग्यास लक थियो। यो हरेक साँझ भयो, तर जब कार मालिकले आइसक्रिम खोज्न धेरै समय बिताए, इन्जिन पर्याप्त चिसो हुन सफल भयो र सजिलै संग सुरु भयो। र जब मानिसले भेनिला आइसक्रिम किन्यो, इन्जिन अझै धेरै तातो थियो र ग्यास लक भंग गर्न समय थिएन।

नैतिक: पूर्णतया पागल समस्याहरू पनि कहिलेकाहीँ वास्तविक हुन्छन्।

दुर्घटना Bandicoot

यो अनुभव गर्न पीडादायी छ। एक प्रोग्रामरको रूपमा, तपाइँ तपाइँको कोडलाई पहिलो, दोस्रो, तेस्रो ... र दस हजारौं स्थानमा तपाइँ कम्पाइलरलाई दोष लगाउने बानी पर्नुहुनेछ। र सूची तल तपाईले पहिले नै उपकरणलाई दोष दिनुहुन्छ।

यहाँ हार्डवेयर बग बारेमा मेरो कथा छ।

क्र्यास ब्यान्डिकुट खेलको लागि, मैले मेमोरी कार्डमा लोड गर्न र बचत गर्न कोड लेखें। यस्तो स्मग खेल विकासकर्ताको लागि, यो पार्कमा हिंड्नु जस्तै थियो: मैले सोचे कि काम धेरै दिन लाग्नेछ। यद्यपि, मैले छ हप्ताको लागि कोड डिबग गर्न समाप्त गरें। बाटोमा, मैले अन्य समस्याहरू समाधान गरें, तर हरेक केही दिनमा म केही घण्टाको लागि यो कोडमा फर्किएँ। यो पीडा थियो।

लक्षण यस्तो देखिन्थ्यो: जब तपाइँ खेलको हालको प्लेथ्रु बचत गर्नुहुन्छ र मेमोरी कार्डमा पहुँच गर्नुहुन्छ, सबै कुरा सधैं ठीक हुन्छ... तर कहिलेकाहीँ कुनै स्पष्ट कारण बिना पढ्न वा लेख्ने सञ्चालनको समय समाप्त हुन्छ। छोटो रेकर्डिङले अक्सर मेमोरी कार्डलाई हानि पुर्‍याउँछ। जब एक खेलाडीले बचत गर्न खोज्छ, उसले बचत गर्न असफल मात्र होइन, नक्सालाई पनि नष्ट गर्दछ। बकवास।

केहि समय पछि, सोनी मा हाम्रो निर्माता, कोनी बस, डराउन थाले। हामीले यो बगको साथ खेल पठाउन सकेनौं, र छ हप्ता पछि मैले समस्या के कारणले गर्दा बुझिन। कोनी मार्फत, हामीले अन्य PS1 विकासकर्ताहरूलाई सम्पर्क गर्‍यौं: के कसैले यस्तै केहि सामना गरेको छ? छैन। मेमोरी कार्डमा कसैलाई समस्या थिएन।

जब तपाईंसँग डिबगिङको लागि कुनै विचार छैन, एक मात्र दृष्टिकोण बायाँ छ "विभाजन र विजय": त्रुटिपूर्ण कार्यक्रमबाट धेरै र धेरै कोडहरू हटाउनुहोस् जबसम्म त्यहाँ एक अपेक्षाकृत सानो टुक्रा बाँकी छैन जसले अझै पनि समस्या निम्त्याउँछ। त्यो हो, तपाईले प्रोग्राम टुक्रा टुक्रा टुक्रा टुक्रा पार्नुहोस् जब सम्म बग रहेको भाग रहन्छ।

तर कुरा के हो भने, भिडियो गेमबाट टुक्राहरू काट्न धेरै गाह्रो छ। यदि तपाईंले गुरुत्वाकर्षणको अनुकरण गर्ने कोड हटाउनुभयो भने यसलाई कसरी चलाउने? वा पात्रहरू कोर्ने?

तसर्थ, हामीले सम्पूर्ण मोड्युलहरूलाई स्टबहरूसँग प्रतिस्थापन गर्नुपर्छ जसले केही उपयोगी काम गर्ने बहाना गर्छ, तर वास्तवमा त्रुटिहरू समावेश गर्न नसक्ने धेरै सरल कार्य गर्नुहोस्। हामीले कम्तिमा कामको लागि खेलको लागि त्यस्ता बैसाखीहरू लेख्नुपर्छ। यो एक ढिलो र पीडादायी प्रक्रिया हो।

छोटकरीमा, मैले गरें। खेल चलाउनको लागि प्रणालीलाई कन्फिगर गर्ने, रेन्डरिङ हार्डवेयर इत्यादि सुरु गर्ने प्रारम्भिक कोड नछोडेसम्म मैले कोडका थप टुक्राहरू हटाएँ। अवश्य पनि, यस चरणमा मैले बचत र लोड मेनु सिर्जना गर्न सकिन, किनकि मैले सबै ग्राफिक्स कोडहरूको लागि स्टब सिर्जना गर्नुपर्नेछ। तर म (अदृश्य) बचत र लोड स्क्रिन प्रयोग गरेर प्रयोगकर्ता भएको बहाना गर्न सक्छु र बचत गर्न सोध्न र त्यसपछि मेमोरी कार्डमा लेख्न सक्छु।

यसले मलाई कोडको सानो टुक्रा छोड्यो जुन अझै माथिको समस्या थियो - तर यो अझै पनि अनियमित रूपमा भइरहेको थियो! प्राय: सबै कुरा राम्रो काम गरे, तर कहिलेकाहीं त्यहाँ glitches थिए। मैले लगभग सबै खेल कोड हटाएँ, तर बग अझै जीवित थियो। यो अचम्मलाग्दो थियो: बाँकी कोडले वास्तवमा केही गरेन।

कुनै बेला, सायद बिहान तीन बजेतिर, मेरो मनमा एउटा विचार आयो। पढ्नुहोस् र लेख्नुहोस् (इनपुट/आउटपुट) सञ्चालनहरूमा सटीक कार्यान्वयन समय समावेश छ। जब तपाइँ हार्ड ड्राइभ, मेमोरी कार्ड वा ब्लुटुथ मोड्युलसँग काम गर्नुहुन्छ, पढ्न र लेख्नको लागि जिम्मेवार निम्न-स्तरको कोडले घडीको पल्स अनुसार गर्छ।

घडीको मद्दतले, प्रोसेसरसँग सीधै जडान नभएको यन्त्रलाई प्रोसेसरमा कार्यान्वयन भइरहेको कोडसँग सिङ्क्रोनाइज गरिन्छ। घडीले बाउड दर निर्धारण गर्छ - डाटा प्रसारण हुने गति। यदि समय संग भ्रम छ भने, कि हार्डवेयर वा सफ्टवेयर, वा दुबै, पनि भ्रमित छन्। र यो धेरै खराब छ, किनभने डाटा क्षतिग्रस्त हुन सक्छ।

के हुन्छ यदि हाम्रो कोडमा केहि समय भ्रमित हुन्छ? मैले परीक्षण कार्यक्रम कोडमा यससँग सम्बन्धित सबै कुरा जाँच गरें र हामीले PS1 मा 1 kHz (1000 टिक्स प्रति सेकेन्ड) मा प्रोग्रामेबल टाइमर सेट गरेको याद गरें। यो एकदम धेरै छ; पूर्वनिर्धारित रूपमा, जब कन्सोल सुरु हुन्छ, यो 100 Hz मा चल्छ। र धेरै जसो खेलहरूले यो आवृत्ति प्रयोग गर्दछ।

एन्डी, खेल विकासकर्ता, टाइमरलाई 1 kHz मा सेट गर्नुहोस् ताकि चालहरू अझ सटीक रूपमा गणना गरिनेछ। एन्डी ओभरबोर्डमा जान्छन्, र यदि हामीले गुरुत्वाकर्षणको अनुकरण गर्छौं भने, हामी यसलाई सकेसम्म सही रूपमा गर्छौं!

तर के हुन्छ यदि टाइमरको गतिलाई कुनै न कुनै रूपमा कार्यक्रमको समग्र समयलाई असर गर्छ, र यसैले मेमोरी कार्डको लागि बाउड दरलाई नियमित गर्ने घडी?

मैले टाइमर कोड टिप्पणी गरें। गल्ती फेरि भएन। तर यसको मतलब यो होइन कि हामीले यसलाई ठीक गर्यौं, किनभने असफलता अनियमित रूपमा भयो। यदि म भाग्यमानी भएँ भने?

केही दिन पछि मैले परीक्षण कार्यक्रमको साथ फेरि प्रयोग गरें। बग दोहोरिएन। म पूर्ण खेल कोडबेसमा फर्किएँ र मेमोरी कार्ड पहुँच गर्नु अघि प्रोग्रामेबल टाइमर यसको मूल मान (100Hz) मा रिसेट हुने गरी बचत र लोड कोड परिमार्जन गरें, र त्यसपछि 1kHz मा रिसेट गर्नुहोस्। त्यहाँ कुनै थप दुर्घटनाहरू थिएनन्।

तर किन यस्तो भयो ?

म फेरि परीक्षा कार्यक्रममा फर्किएँ। मैले 1 kHz टाइमरको साथ त्रुटिको घटनामा केही ढाँचा फेला पार्ने प्रयास गरें। अन्ततः मैले याद गरें कि त्रुटि तब हुन्छ जब कसैले PS1 नियन्त्रकसँग खेल्छ। किनकि म आफैंले यो विरलै गर्छु - किन बचत र लोड कोड परीक्षण गर्दा मलाई नियन्त्रक चाहिन्छ? - मैले यो निर्भरतालाई पनि याद गरेन। तर एक दिन हाम्रा एकजना कलाकारले मेरो परीक्षण समाप्त गर्नको लागि पर्खिरहेका थिए - म सायद त्यस क्षणमा श्राप दिइरहेको थिएँ - र डराएर आफ्नो हातमा नियन्त्रक घुमाए। त्रुटी देखा पर्यो। "पर्खनुहोस्, के?!" खैर, यो फेरि गर्नुहोस्! ”

जब मैले महसुस गरें कि यी दुई घटनाहरू आपसमा जोडिएका थिए, मैले सजिलैसँग त्रुटि पुन: उत्पादन गर्न सक्षम भएँ: मैले मेमोरी कार्डमा रेकर्ड गर्न थालें, नियन्त्रक सारियो, र मेमोरी कार्डलाई बर्बाद गरें। मलाई यो हार्डवेयर बग जस्तै देखिन्थ्यो।

म कोनीकहाँ आएँ र उसलाई मेरो खोजको बारेमा बताए। उनले PS1 डिजाइन गर्ने इन्जिनियरहरू मध्ये एकलाई जानकारी रिले गरिन्। "असम्भव," उनले जवाफ दिए, "यो हार्डवेयर समस्या हुन सक्दैन।" मैले कोनीलाई हाम्रो लागि कुराकानीको व्यवस्था गर्न आग्रह गरें।

इन्जिनियरले मलाई बोलाए र हामीले उसको टुटेको अंग्रेजी र मेरो (अत्यधिक) टुटेको जापानीमा बहस गर्यौं। अन्तमा मैले भने, "मलाई मेरो 30 लाइन परीक्षण कार्यक्रम पठाउन दिनुहोस् जहाँ नियन्त्रक सार्दा बग हुन्छ।" उनी सहमत भए। उनले भने कि यो समयको बर्बादी थियो र उनी नयाँ परियोजनामा ​​काम गर्न अत्यन्तै व्यस्त थिए, तर हामी सोनीका लागि धेरै महत्त्वपूर्ण विकासकर्ता भएकाले स्वीकार गर्नेछौं। मैले मेरो परीक्षण कार्यक्रम सफा गरे र उहाँलाई पठाए।

भोलिपल्ट साँझ (हामी लस एन्जलसमा थियौं र उहाँ टोकियोमा हुनुहुन्थ्यो) उसले मलाई फोन गर्‍यो र माफी मागे। यो एक हार्डवेयर समस्या थियो।

मलाई वास्तवमा बग के थियो थाहा छैन, तर मैले सोनी मुख्यालयमा सुनेको कुराबाट, यदि तपाईंले टाइमरलाई पर्याप्त उच्च मूल्यमा सेट गर्नुभयो भने, यसले टाइमर क्रिस्टलको वरपरको मदरबोर्डमा कम्पोनेन्टहरूमा हस्तक्षेप गर्‍यो। ती मध्ये एक मेमोरी कार्डको लागि बाउड दर नियन्त्रक थियो, जसले नियन्त्रकहरूको लागि बाड दर पनि सेट गर्यो। म इन्जिनियर होइन, त्यसैले मैले केहि गडबड गरेको हुन सक्छ।

तर तल्लो रेखा यो हो कि मदरबोर्डमा कम्पोनेन्टहरू बीचको हस्तक्षेप थियो। र 1 kHz मा चलिरहेको टाइमरको साथ कन्ट्रोलर पोर्ट र मेमोरी कार्ड पोर्ट मार्फत एकैसाथ डाटा ट्रान्समिट गर्दा, बिटहरू हराए, डाटा हराए, र कार्ड बिग्रियो।

खराब गाईहरू

1980 को दशकमा, मेरो सल्लाहकार सर्गेईले SM-1800 को लागि सफ्टवेयर लेख्नुभयो, PDP-11 को सोभियत क्लोन। यो माइक्रो कम्प्यूटर भर्खरै USSR मा एक महत्त्वपूर्ण यातायात हब Sverdlovsk नजिकैको रेलवे स्टेशनमा स्थापना गरिएको छ। नयाँ प्रणाली वैगनहरू र माल ढुवानीलाई रुट गर्न डिजाइन गरिएको थियो। तर यसमा एक कष्टप्रद बग थियो जसले अनियमित क्र्यास र क्र्यासहरू निम्त्याउँछ। साँझ कोही घर गएको बेला झरना सधैं हुन्थ्यो। तर अर्को दिन पूर्ण अनुसन्धानको बावजुद, कम्प्युटरले सबै म्यानुअल र स्वचालित परीक्षणहरूमा सही रूपमा काम गर्यो। यसले सामान्यतया दौड अवस्था वा केही अन्य प्रतिस्पर्धी बगलाई संकेत गर्दछ जुन निश्चित परिस्थितिहरूमा हुन्छ। राति ढिलो कलहरूबाट थकित, सर्गेईले यसको तल पुग्ने निर्णय गरे, र सबै भन्दा पहिले, मार्शलिङ यार्डमा कम्प्यूटर ब्रेकडाउनको कारण के अवस्थाहरू बुझे।

पहिले, उनले सबै अज्ञात झरनाहरूको तथ्याङ्क सङ्कलन गरे र मिति र समय अनुसार ग्राफ सिर्जना गरे। ढाँचा स्पष्ट थियो। केही दिनको लागि अवलोकन गरेपछि, सर्गेईले महसुस गरे कि उसले भविष्यको प्रणाली विफलताको समय सजिलैसँग भविष्यवाणी गर्न सक्छ।

उसले चाँडै थाहा पायो कि स्टेशनले उत्तरी युक्रेन र पश्चिमी रूसबाट गाईवस्तुहरूका रेलहरू क्रमबद्ध गर्दै नजिकैको वधशालामा जाँदा मात्र अवरोधहरू उत्पन्न भएको थियो। यो आफैंमा अनौठो थियो, किनकि कजाकिस्तानको धेरै नजिकै अवस्थित फार्महरूद्वारा वधशाला आपूर्ति गरिएको थियो।

1986 मा चेर्नोबिल आणविक पावर प्लान्ट विस्फोट भयो, र रेडियोधर्मी नतिजाले वरपरका क्षेत्रहरूलाई बस्न योग्य बनायो। उत्तरी युक्रेन, बेलारुस र पश्चिमी रूसका विशाल क्षेत्रहरू दूषित थिए। आइपुगेका गाडीहरूमा विकिरणको उच्च स्तरको शंका गर्दै, सर्गेईले यो सिद्धान्त परीक्षण गर्न एक विधि विकास गरे। जनसंख्यालाई डोसिमिटर हुनबाट निषेध गरिएको थियो, त्यसैले सर्गेईले रेलवे स्टेशनमा धेरै सैन्य पुरुषहरूसँग दर्ता गरे। भोड्काको धेरै पेय पछि, उसले एक सैनिकलाई शंकास्पद गाडीमा विकिरण स्तर मापन गर्न मनाउन सफल भयो। यो स्तर सामान्य मान भन्दा धेरै गुणा उच्च थियो कि बाहिर भयो।

गाईवस्तुहरूले धेरै विकिरणहरू मात्र उत्सर्जन गर्दैनन्, यसको स्तर यति उच्च थियो कि यसले SM-1800 को सम्झनामा बिट्सको अनियमित क्षति निम्त्यायो, जुन स्टेशनको छेउमा एउटा भवनमा अवस्थित थियो।

सोभियत संघमा खाद्यान्न अभाव थियो, र अधिकारीहरूले चेर्नोबिल मासुलाई देशका अन्य क्षेत्रहरूको मासुसँग मिलाउने निर्णय गरे। यसले बहुमूल्य स्रोतहरू गुमाउन बिना रेडियोएक्टिभिटीको समग्र स्तर कम गर्न सम्भव बनायो। यस बारे थाहा पाएपछि, सर्गेईले तुरुन्तै प्रवासको लागि कागजातहरू भरे। र कम्प्यूटर क्र्यासहरू आफैंमा रोकियो जब विकिरण स्तर समय संग घट्यो।

पाइपहरू मार्फत

एक पटक, Movietech Solutions ले सिनेमाघरहरूको लागि सफ्टवेयर सिर्जना गर्यो, लेखा, टिकट बिक्री र सामान्य व्यवस्थापनको लागि डिजाइन गरिएको। फ्ल्यागशिप एपको DOS संस्करण उत्तरी अमेरिकामा सानो र मध्यम आकारको चलचित्र थिएटर चेनहरू बीच धेरै लोकप्रिय थियो। त्यसैले यो आश्चर्यजनक छैन कि जब Windows 95 संस्करण घोषणा गरियो, नवीनतम टच स्क्रिनहरू र सेल्फ-सर्भिस किओस्कहरूसँग एकीकृत, र सबै प्रकारका रिपोर्टिङ उपकरणहरूसँग सुसज्जित, यो छिट्टै लोकप्रिय भयो। प्राय: अद्यावधिक समस्या बिना गयो। स्थानीय IT कर्मचारीहरूले नयाँ उपकरणहरू स्थापना गरे, डेटा माइग्रेट गरे, र व्यापार जारी राख्यो। बाहेक जब यो टिकेन। जब यो भयो, कम्पनीले जेम्सलाई "द क्लीनर" उपनाम पठाउनेछ।

यद्यपि उपनामले नराम्रो प्रकारको सुझाव दिन्छ, क्लिनर भनेको प्रशिक्षक, स्थापनाकर्ता र ज्याक-अफ-अल-ट्रेडहरूको संयोजन मात्र हो। जेम्सले ग्राहकको साइटमा सबै कम्पोनेन्टहरू सँगै राखेर केही दिनहरू बिताउनेछन्, र त्यसपछि कर्मचारीहरूलाई नयाँ प्रणाली कसरी प्रयोग गर्ने भनेर सिकाउन, उत्पन्न हुने हार्डवेयर समस्याहरू समाधान गर्न र सफ्टवेयरलाई यसको बाल्यावस्थामा अनिवार्य रूपमा मद्दत गर्न थप केही दिन बिताउनेछन्।

त्यसकारण, यो अचम्मको कुरा होइन कि यी व्यस्त समयमा, जेम्स बिहान अफिसमा आइपुगे, र उसको डेस्कमा पुग्नु अघि, उसलाई प्रबन्धकले स्वागत गरे, सामान्य भन्दा बाहिर क्याफिनले भरिएको थियो।

"मलाई डर छ कि तपाईले जतिसक्दो चाँडो अन्नापोलिस, नोभा स्कोटिया जानु पर्छ।" तिनीहरूको सम्पूर्ण प्रणाली तल गयो, र तिनीहरूका इन्जिनियरहरूसँग काम गरेको एक रात पछि, हामी के भयो भनेर पत्ता लगाउन सक्दैनौं। सर्भरमा नेटवर्क असफल भएको जस्तो देखिन्छ। तर केही मिनेटसम्म प्रणाली सञ्चालनमा आएपछि मात्रै ।

- तिनीहरू पुरानो प्रणालीमा फर्किएनन्? - जेम्सले पूर्ण रूपमा गम्भीर रूपमा जवाफ दिए, यद्यपि मानसिक रूपमा उसले आश्चर्यमा आफ्नो आँखा फराकिलो पार्यो।

- ठ्याक्कै: तिनीहरूको आईटी विशेषज्ञले "प्राथमिकताहरू परिवर्तन गरे" र तिनीहरूको पुरानो सर्भरको साथ छोड्ने निर्णय गरे। जेम्स, तिनीहरूले छ साइटहरूमा प्रणाली स्थापना गरे र भर्खरै प्रिमियम समर्थनको लागि भुक्तान गरे, र तिनीहरूको व्यवसाय अहिले 1950 को दशकमा जस्तै चलिरहेको छ।

जेम्स अलिकति सीधा भयो।

- त्यो अर्को कुरा हो। ठीक छ, सुरु गरौं।

जब उनी अन्नापोलिसमा आइपुगे, उनले पहिलो कुरा ग्राहकको पहिलो थियेटर फेला पारे जसमा समस्या थियो। एयरपोर्टमा लिइएको नक्सामा, सबै कुरा सभ्य देखिन्थ्यो, तर इच्छित ठेगाना वरपरको क्षेत्र शंकास्पद देखिन्थ्यो। बस्ती होइन, तर फिल्म नोयरको सम्झना दिलाउँछ। जेम्स कर्ब डाउनटाउनमा पार्क गर्दा, एउटी वेश्या उनको नजिक आई। अन्नापोलिसको आकारलाई हेर्दा, यो सम्भवतः सम्पूर्ण शहरमा एक मात्र थियो। उनको उपस्थितिले तुरुन्तै ठूलो पर्दामा पैसाको लागि सेक्स प्रस्ताव गर्ने प्रसिद्ध चरित्रको दिमागमा ल्यायो। होइन, जुलिया रोबर्ट्सको बारेमा होइन, तर जोन भोइटको बारेमा [फिल्म "मिडनाइट काउबॉय" को संकेत - लगभग। लेन].

वेश्यालाई आफ्नो बाटोमा पठाएपछि, जेम्स सिनेमा गए। वरपरको क्षेत्र राम्रो भएको थियो, तर यसले अझै पनि तल झरेको छाप दियो। जेम्स धेरै चिन्तित थिएनन्। उनी यसअघि पनि दुर्गम ठाउँमा गएका थिए । र यो क्यानाडा थियो, जहाँ लुटेराहरू पनि तपाईंको वालेट लिएपछि "धन्यवाद" भन्न पर्याप्त विनम्र हुन्छन्।

सिनेमा घरको छेउको प्रवेशद्वार अँध्यारो गल्लीमा थियो। जेम्स ढोकामा गएर ढकढक्याए। चाँडै त्यो चर्कियो र थोरै खुल्यो।

- के तपाई क्लिनर हुनुहुन्छ? - भित्रबाट कर्कश आवाज आयो।

- हो, यो म हुँ ... म सबै ठीक गर्न आएको हुँ।

जेम्स सिनेमा लबीमा गए। स्पष्ट रूपमा अर्को विकल्प नभएको, कर्मचारीहरूले आगन्तुकहरूलाई कागजी टिकटहरू दिन थाले। यसले वित्तीय रिपोर्टिङलाई गाह्रो बनायो, अझ रोचक विवरणहरू छोड्नुहोस्। तर कर्मचारीहरूले जेम्सलाई राहतका साथ स्वागत गरे र तुरुन्तै उनलाई सर्भर कोठामा लगे।

पहिलो नजर मा, सबै ठीक थियो। जेम्सले सर्भरमा लगइन गरे र सामान्य संदिग्ध ठाउँहरू जाँच गरे। समस्या छैन। यद्यपि, धेरै सावधानी अपनाएर, जेम्सले सर्भर बन्द गरे, नेटवर्क कार्ड बदले, र प्रणालीलाई फिर्ता गरे। उनले तुरुन्तै पूर्ण रूपमा काम गर्न थाले। कर्मचारीले फेरि टिकट बेच्न थाले ।

जेम्सले मार्कलाई बोलाएर अवस्थाबारे जानकारी दिए। यो कल्पना गर्न गाह्रो छैन कि जेम्स वरिपरि रहन र केहि अप्रत्याशित हुन्छ कि भनेर हेर्न चाहन्छ। उनी सिँढीबाट ओर्लिए र कर्मचारीहरूलाई के भयो भनेर सोध्न थाले। पक्कै पनि प्रणालीले काम गर्न छोडेको छ। तिनीहरूले यसलाई बन्द र अन, सबै काम गरे। तर १० मिनेटपछि प्रणाली बन्द भयो ।

यतिबेला मात्र यस्तै भएको छ । अचानक, टिकट प्रणाली त्रुटिहरू फेंक गर्न थाले। कर्मचारीहरूले सास फेरे र कागजको टिकटहरू समाते, र जेम्स हतार-हतार सर्भर कोठामा गए। सर्भर संग सबै राम्रो देखिन्थ्यो।

त्यसपछि एकजना कर्मचारी भित्र पसे ।

- प्रणाली फेरि काम गर्दैछ।

जेम्स हैरान थिए किनभने उसले केहि नगरेको थियो। अझ स्पष्ट रूपमा, प्रणालीले काम गर्न सक्ने केहि पनि छैन। उसले लग आउट गर्यो, आफ्नो फोन उठायो, र आफ्नो कम्पनीको समर्थन लाइनमा कल गर्यो। एकैछिनमा त्यही कर्मचारी सर्भर रुममा प्रवेश गरे ।

- प्रणाली तल छ।

जेम्सले सर्भरमा हेरे। बहु-रंगीन आकारहरूको एक रोचक र परिचित ढाँचा स्क्रिनमा नाच्यो - अराजक रूपमा राइथिङ र पाइपहरू जोड्ने। हामीले यो स्क्रिनसेभरलाई कुनै न कुनै समयमा देखेका छौं। यो सुन्दर ढंगले प्रस्तुत गरिएको थियो र शाब्दिक रूपमा सम्मोहन थियो।

जेम्सले बटन थिचे र ढाँचा गायब भयो। उनी हतार हतार टिकट अफिसमा पुगे र बाटोमा एकजना कर्मचारीलाई भेटे ।

- प्रणाली फेरि काम गर्दैछ।

यदि तपाइँ मानसिक अनुहारको हत्केला गर्न सक्नुहुन्छ भने, जेम्सले के गरे। स्क्रिन सेभर। यसले OpenGL प्रयोग गर्दछ। र यसैले, सञ्चालनको समयमा, यसले सर्भर प्रोसेसरको सबै स्रोतहरू उपभोग गर्दछ। नतिजाको रूपमा, सर्भरमा प्रत्येक कल टाइमआउटको साथ समाप्त हुन्छ।

जेम्स सर्भर कोठामा फर्किए, लगइन गरे, र स्क्रिनसेभरलाई खाली स्क्रिनको साथ सुन्दर पाइपहरूले बदले। त्यो हो, प्रोसेसर स्रोतहरूको 100% खपत गर्ने स्क्रिनसेभरको सट्टा, मैले स्रोतहरू खपत नगर्ने अर्को स्थापना गरें। त्यसपछि मैले मेरो अनुमान जाँच गर्न 10 मिनेट पर्खें।

जब जेम्स अर्को सिनेमामा आइपुगे, उनी आफ्नो प्रबन्धकलाई कसरी स्क्रिन सेभर बन्द गर्न भर्खरै 800 किलोमिटर उडेको कुरा बुझाउने भनेर सोचिरहेका थिए।

चन्द्रमा को एक निश्चित चरण को समयमा दुर्घटना

सत्य कथा। एक दिन एक सफ्टवेयर बग उठ्यो जुन चन्द्रमाको चरणमा निर्भर थियो। त्यहाँ एक सानो दिनचर्या थियो जुन सामान्यतया चन्द्रमाको वास्तविक चरणको अनुमानित गणना गर्न विभिन्न MIT कार्यक्रमहरूमा प्रयोग गरिएको थियो। GLS ले यो दिनचर्यालाई LISP कार्यक्रममा बनायो जसले फाइल लेख्दा, लगभग 80 क्यारेक्टर लामो टाइमस्ट्याम्पको साथ लाइन आउटपुट गर्नेछ। यो धेरै दुर्लभ थियो कि सन्देशको पहिलो लाइन धेरै लामो हुन सक्छ र अर्को लाइनमा लैजान्छ। र जब कार्यक्रम पछि यो फाइल पढे, यो सराप्यो। पहिलो रेखाको लम्बाइ सही मिति र समय, साथै टाइमस्ट्याम्प छापिएको समयमा चरण विशिष्टताको लम्बाइमा निर्भर हुन्छ। त्यो हो, बग शाब्दिक रूपमा चन्द्रमाको चरणमा निर्भर थियो!

पहिलो पेपर संस्करण शब्दजाल फाइल (Steele-1983) ले वर्णन गरिएको बगको नेतृत्व गर्ने यस्तो रेखाको उदाहरण समावेश गर्यो, तर टाइपसेटरले यसलाई "फिक्स" गर्यो। यसलाई पछि "चन्द्र चरण बग" को रूपमा वर्णन गरिएको छ।

यद्यपि, अनुमानहरूसँग सावधान रहनुहोस्। केही वर्ष पहिले, CERN (युरोपियन सेन्टर फर न्यूक्लियर रिसर्च) का इन्जिनियरहरूले ठूलो इलेक्ट्रोन-पोजिट्रोन कोलाइडरमा गरिएका प्रयोगहरूमा त्रुटिहरू सामना गरे। किनभने कम्प्युटरहरूले वैज्ञानिकहरूलाई नतिजा देखाउनु अघि यस यन्त्रबाट उत्पन्न हुने डाटाको ठूलो मात्रालाई सक्रिय रूपमा प्रशोधन गर्ने भएकाले, धेरैले अनुमान गरे कि सफ्टवेयर कुनै न कुनै रूपमा चन्द्रमाको चरणमा संवेदनशील थियो। धेरै हताश इन्जिनियरहरू सत्यको फेदमा पुगे। चन्द्रमाको पारिस्थितिमा पृथ्वीको विकृतिका कारण २७ किलोमिटर लामो रिंगको ज्यामितिमा अलिकति परिवर्तन हुँदा त्रुटि उत्पन्न भएको हो! यस कथाले भौतिकशास्त्रको लोककथामा "कण भौतिकीमा न्यूटनको बदला" र भौतिक विज्ञानको सबैभन्दा सरल र पुरानो नियमहरू र सबैभन्दा उन्नत वैज्ञानिक अवधारणाहरू बीचको सम्बन्धको उदाहरणको रूपमा प्रवेश गरेको छ।

शौचालय फ्लस गर्दा रेल रोकिन्छ

मैले सुनेको सबैभन्दा राम्रो हार्डवेयर बग फ्रान्सको उच्च गतिको ट्रेनमा थियो। बगले ट्रेनको आपतकालीन ब्रेक लगायो, तर बोर्डमा यात्रुहरू भए मात्र। प्रत्येक यस्तो अवस्थामा, ट्रेन सेवाबाट हटाइयो, जाँच गरियो, तर केहि फेला परेन। त्यसपछि उसलाई लाइनमा फिर्ता पठाइयो, र ऊ तुरुन्तै एक स्टपमा क्र्यास भयो।

एउटा जाँचको क्रममा, रेलमा यात्रा गरिरहेका एक इन्जिनियर शौचालय गए। ऊ चाँडै धोए, बूम! आपतकालीन रोक।

इन्जिनियरले चालकलाई सम्पर्क गरे र सोधे:

- तपाईं ब्रेक लगाउनु अघि के गर्दै हुनुहुन्थ्यो?

- ठिक छ, म तल ओर्लिएर सुस्त...

यो अनौठो थियो, किनकि सामान्य सञ्चालनको क्रममा रेल दर्जनौं पटक अवतरणमा ढिलो हुन्छ। ट्रेन अघि बढ्यो, र अर्को झरनामा चालकले चेतावनी दियो:

- म ढिलो गर्न जाँदैछु।

केही भएन।

- तपाईंले पछिल्लो ब्रेकिङ समयमा के गर्नुभयो? - चालकले सोधे।

- ठीक छ ... म शौचालयमा थिएँ ...

- ठीक छ, त्यसपछि शौचालय जानुहोस् र हामी फेरि तल जाँदा तपाईंले के गर्नुभयो!

इन्जिनियर शौचालय गए, र जब ड्राइभरले चेतावनी दिए: "म ढिलो गर्दैछु," उसले पानी फ्लश गर्यो। अवश्य पनि, रेल तुरुन्तै रोकियो।

अब तिनीहरूले समस्या पुन: उत्पादन गर्न सक्छन् र कारण खोज्न आवश्यक छ।

दुई मिनेट पछि, तिनीहरूले इन्जिन ब्रेक रिमोट कन्ट्रोल केबल (रेलको प्रत्येक छेउमा एउटा इन्जिन थियो) बिजुली क्याबिनेटको पर्खालबाट विच्छेद भएको र शौचालय प्लग सोलेनोइडलाई नियन्त्रण गर्ने रिलेमा सुतिरहेको याद गरे... जब रिले खोलिएको थियो, यसले ब्रेक केबलमा हस्तक्षेप सिर्जना गर्‍यो, र विफलताहरू विरुद्ध प्रणाली सुरक्षामा आपतकालीन ब्रेकिङ समावेश थियो।

फोरट्रानलाई घृणा गर्ने गेटवे

केही महिना अघि हामीले देख्यौं कि मुख्य भूमिमा नेटवर्क जडानहरू [यो हवाईमा थियो] धेरै, धेरै ढिलो हुँदै गइरहेको थियो। यो 10-15 मिनेटको लागि रहन सक्छ र त्यसपछि अचानक फेरि हुन सक्छ। केहि समय पछि, मेरो सहकर्मीले मलाई गुनासो गरे कि मुख्य भूमिमा नेटवर्क जडानहरू सामान्यतया काम गर्दैन। उहाँसँग केही FORTRAN कोड थियो जुन मुख्य भूमिमा रहेको मेसिनमा प्रतिलिपि गर्न आवश्यक थियो, तर यो हुन सकेन किनभने "नेटवर्कले FTP अपलोड पूरा हुनको लागि पर्याप्त समयसम्म टिकेन।"

हो, यो पत्ता लाग्यो कि नेटवर्क विफलता भयो जब एक सहकर्मीले FORTRAN मा स्रोत कोड भएको फाइललाई मुख्य भूमिमा रहेको मेसिनमा FTP गर्ने प्रयास गरे। हामीले फाइललाई सङ्ग्रह गर्ने प्रयास गर्यौं: त्यसपछि यसलाई सजिलै प्रतिलिपि गरियो (तर लक्षित मेसिनमा अनप्याकर थिएन, त्यसैले समस्या समाधान भएन)। अन्तमा हामीले FORTRAN कोडलाई धेरै सानो टुक्राहरूमा "विभाजित" गर्यौं र तिनीहरूलाई एक पटकमा पठायौं। अधिकांश टुक्राहरू समस्या बिना प्रतिलिपि गरिएको थियो, तर केही टुक्राहरू पास भएनन्, वा पछि पास भएनन् धेरै प्रयासहरू।

समस्याग्रस्त खण्डहरूको जाँच गरेपछि, हामीले पत्ता लगायौं कि तिनीहरूमा केहि समान छ: तिनीहरू सबैमा टिप्पणी ब्लकहरू छन् जुन क्यापिटल C (एक सहकर्मीको रूपमा FORTRAN मा टिप्पणी गर्न रुचाउने) समावेश भएको लाइनहरूसँग सुरु र अन्त्य हुन्छ। हामीले मुख्य भूमिमा नेटवर्क विशेषज्ञहरूलाई इमेल गर्यौं र मद्दतको लागि सोध्यौं। निस्सन्देह, तिनीहरू FTP मार्फत स्थानान्तरण गर्न नसकिने हाम्रा फाइलहरूको नमूनाहरू हेर्न चाहन्थे... तर हाम्रा पत्रहरू उनीहरूमा पुगेनन्। अन्ततः हामी एउटा साधारण साथ आयौं वर्णन गर्नुहोस्गैर-स्थानान्तरणयोग्य फाइलहरू कस्तो देखिन्छन्। यसले काम गर्‍यो :) [म यहाँ समस्याग्रस्त फोरट्रान टिप्पणीहरूको एउटा उदाहरण थप्ने हिम्मत गर्छु? सायद यो लायक छैन!]

अन्तमा हामीले यो पत्ता लगाउन सफल भयौं। क्याम्पसको हाम्रो भाग र मुख्य भूमि नेटवर्कको बीचमा हालै एउटा नयाँ गेटवे स्थापना गरिएको थियो। यसलाई ठूला अक्षर C को दोहोर्याइएको बिटहरू समावेश गर्ने प्याकेटहरू प्रसारण गर्न ठूलो कठिनाई थियो! यी मध्ये केही प्याकेटहरूले सबै गेटवे स्रोतहरू लिन सक्छन् र धेरैजसो अन्य प्याकेटहरू मार्फत जानबाट रोक्न सक्छन्। हामीले गेटवे निर्मातालाई गुनासो गर्यौं ... र तिनीहरूले जवाफ दिए: "ओह, हो, तपाइँ बारम्बार C को बगको सामना गर्दै हुनुहुन्छ! उहाँको बारेमा हामीलाई पहिले नै थाहा छ। ” हामीले अन्ततः अर्को निर्माताबाट नयाँ गेटवे खरिद गरेर समस्या समाधान गर्यौं (पूर्वको रक्षामा, FORTRAN कार्यक्रमहरू स्थानान्तरण गर्न असक्षमता केहीको लागि फाइदा हुन सक्छ!)।

कठिन समय

केही वर्ष पहिले, चरण 40 क्लिनिकल परीक्षणहरूको लागत कम गर्न पर्लमा ETL प्रणाली सिर्जना गर्ने क्रममा, मैले लगभग 000 मितिहरू प्रशोधन गर्न आवश्यक थियो। तीमध्ये दुई जना परीक्षामा उत्तीर्ण भएनन् । यसले मलाई धेरै चिन्तित पारेन किनभने यी मितिहरू ग्राहक-प्रदान गरिएको डाटाबाट लिइएका थिए जुन प्रायः, हामी भन्न सक्छौं, अचम्मको कुरा। तर जब मैले मूल डाटा जाँच गरें, यो पत्ता लाग्यो कि यी मितिहरू जनवरी 1, 2011 र जनवरी 1, 2007 थिए। मैले सोचे कि बग मैले भर्खरै लेखेको कार्यक्रममा समावेश छ, तर यो पहिले नै 30 वर्ष भइसकेको थियो। पुरानो। यो सफ्टवेयर इकोसिस्टमसँग अपरिचित व्यक्तिहरूलाई रहस्यमय लाग्न सक्छ। पैसा कमाउने अर्को कम्पनीको लामो समयदेखिको निर्णयको कारण, मेरो क्लाइन्टले मलाई एउटा कम्पनीले दुर्घटनामा र अर्कोले उद्देश्यमा प्रस्तुत गरेको बग समाधान गर्न भुक्तान गर्यो। मैले के कुरा गरिरहेको छु भनेर तपाईंले बुझ्नको लागि, मैले बग बन्ने सुविधा थपेको कम्पनीको बारेमा कुरा गर्न आवश्यक छ, साथै मैले फिक्स गरेको रहस्यमय बगमा योगदान गर्ने केही अन्य रोचक घटनाहरू।

राम्रो पुरानो दिनहरूमा, एप्पल कम्प्युटरहरूले कहिलेकाहीं जनवरी 1, 1904 मा आफ्नो मिति रिसेट गर्थे। कारण सरल थियो: यसले मिति र समय ट्र्याक राख्न ब्याट्री-संचालित "प्रणाली घडी" प्रयोग गर्‍यो। ब्याट्री मर्दा के भयो? कम्प्यूटरले एक युगको सुरुदेखि सेकेन्डको संख्यामा मिति ट्र्याक गर्न थाले। युगले हामीले सन्दर्भको मूल मिति भनेको थियो, र Macintoshes को लागि यो जनवरी 1, 1904 थियो। र ब्याट्रीको मृत्यु पछि, हालको मिति तोकिएको मितिमा रिसेट गरियो। तर किन यस्तो भयो ?

पहिले, एप्पलले मूल मितिदेखि सेकेन्डको संख्या भण्डारण गर्न 32 बिटहरू प्रयोग गर्‍यो। एक बिटले दुई मध्ये एउटा मान भण्डारण गर्न सक्छ - १ वा ०। दुई बिटले चार मान मध्ये एउटा भण्डारण गर्न सक्छ: ००, ०१, १०, ११। तीन बिट्स - आठ मध्ये एउटा मान: 1, 0, 00, 01, 10 , 11, 000, 001, आदि। र 010 ले 011 मान मध्ये एउटा भण्डारण गर्न सक्छ, त्यो हो, 100 सेकेन्ड। एप्पल मितिहरूको लागि, यो लगभग 101 वर्ष बराबर छ, त्यसैले पुराना म्याकहरूले 110 पछि मितिहरू ह्यान्डल गर्न सक्दैनन्। र यदि प्रणालीको ब्याट्री मर्छ भने, मिति युगको सुरुदेखि ० सेकेन्डमा रिसेट हुन्छ, र तपाईंले कम्प्युटर खोल्दा प्रत्येक पटक (वा तपाईंले नयाँ ब्याट्री किन्नुभएसम्म) मिति म्यानुअल रूपमा सेट गर्नुपर्नेछ।

यद्यपि, एपोचको सेकेन्डको रूपमा मितिहरू भण्डारण गर्ने निर्णयको मतलब यो हो कि हामीले युग भन्दा पहिले मितिहरू प्रशोधन गर्न सक्दैनौं, जसको दूरगामी परिणामहरू थिए, हामी देख्नेछौं। एप्पलले बग होइन, सुविधा प्रस्तुत गर्‍यो। अन्य चीजहरूको बीचमा, यसको मतलब यो थियो कि Macintosh अपरेटिङ सिस्टम "सहस्राब्दी बग" (जसलाई प्रतिबन्धहरू हटाउन आफ्नै मिति प्रणालीहरू भएका धेरै म्याक अनुप्रयोगहरूको बारेमा भन्न सकिँदैन) प्रतिरक्षा थियो।

अघि बढ। हामीले लोटस 1-2-3 प्रयोग गर्यौं, IBM को "हत्यारा अनुप्रयोग" जसले PC क्रान्ति सुरु गर्न मद्दत गर्‍यो, यद्यपि Apple कम्प्युटरहरूमा VisiCalc थियो, जसले व्यक्तिगत कम्प्युटरलाई सफल बनायो। निष्पक्षतामा, यदि 1-2-3 देखा परेको थिएन भने, पीसीहरू शायद नै बन्द हुने थिए, र व्यक्तिगत कम्प्युटरहरूको इतिहास धेरै फरक रूपमा विकसित हुन सक्छ। लोटस 1-2-3 ले 1900 लाई लीप वर्षको रूपमा गलत रूपमा व्यवहार गर्यो। जब माइक्रोसफ्टले आफ्नो पहिलो स्प्रेडसिट, मल्टिप्लान जारी गर्यो, यसले बजारको सानो हिस्सा कब्जा गर्यो। र जब तिनीहरूले एक्सेल परियोजना सुरु गरे, तिनीहरूले लोटस 1-2-3 बाट पङ्क्ति र स्तम्भ नामकरण योजना प्रतिलिपि गर्ने मात्र होइन, तर 1900 लाई लीप वर्षको रूपमा जानाजानी व्यवहार गरेर बग अनुकूलता सुनिश्चित गर्ने निर्णय गरे। यो समस्या आज पनि छ । अर्थात्, 1-2-3 मा यो एक बग थियो, तर Excel मा यो एक सचेत निर्णय थियो जसले सुनिश्चित गर्यो कि सबै 1-2-3 प्रयोगकर्ताहरूले डेटा परिवर्तन नगरी आफ्नो तालिकाहरू Excel मा आयात गर्न सक्छन्, यो गलत भए पनि।

तर त्यहाँ अर्को समस्या थियो। पहिलो, माइक्रोसफ्टले म्याकिन्टोसको लागि एक्सेल जारी गर्‍यो, जसले जनवरी 1, 1904 अघिको मितिहरू पहिचान गर्दैन। र एक्सेलमा, जनवरी 1, 1900 लाई युगको सुरुवात मानिन्थ्यो। तसर्थ, विकासकर्ताहरूले परिवर्तन गरे ताकि तिनीहरूको कार्यक्रमले युगको प्रकार पहिचान गर्यो र इच्छित युगको अनुसार आफैंमा डाटा भण्डारण गर्यो। माइक्रोसफ्टले यसको बारेमा व्याख्यात्मक लेख पनि लेख्यो। र यो निर्णयले मेरो बग निम्त्यायो।

मेरो ETL प्रणालीले ग्राहकहरूबाट एक्सेल स्प्रेडसिटहरू प्राप्त गर्यो जुन Windows मा सिर्जना गरिएको थियो, तर म्याकमा पनि सिर्जना गर्न सकिन्छ। तसर्थ, तालिकामा युगको सुरुवात जनवरी 1, 1900, वा जनवरी 1, 1904 हुन सक्छ। कसरी पत्ता लगाउने? एक्सेल फाइल ढाँचाले आवश्यक जानकारी देखाउँछ, तर मैले प्रयोग गरेको पार्सरले यसलाई देखाउन सकेन (अहिले यसले गर्छ), र तपाइँलाई एक विशिष्ट तालिकाको लागि युग थाहा छ भनेर मानिन्छ। मैले सायद एक्सेल बाइनरी ढाँचा बुझ्न र पार्सर लेखकलाई प्याच पठाउन धेरै समय बिताउन सक्थें, तर मसँग क्लाइन्टका लागि धेरै कुराहरू थिए, त्यसैले मैले चाँडै नै युग निर्धारण गर्नको लागि एक हेरिस्टिक लेखें। उनी सरल थिइन् ।

एक्सेलमा, मिति जुलाई 5, 1998 लाई "07-05-98" (बेकार अमेरिकी प्रणाली), "जुलाई 5, 98", "जुलाई 5, 1998", "5-जुलाई-98" वा ढाँचामा प्रतिनिधित्व गर्न सकिन्छ। केही अन्य ढाँचा। अर्को बेकार ढाँचा (विडम्बनाको रूपमा, मेरो एक्सेलको संस्करणले प्रस्ताव नगरेको ढाँचाहरू मध्ये एउटा ISO 8601 थियो)। जे होस्, तालिका भित्र, अनफर्म्याट गरिएको मिति कि त epoch-35981 को लागि "1900" वा epoch-34519 को लागि "1904" को रूपमा भण्डार गरिएको थियो (संख्याहरूले युगदेखि दिनहरूको सङ्ख्यालाई प्रतिनिधित्व गर्दछ)। मैले ढाँचा गरिएको मितिबाट वर्ष निकाल्न सरल पार्सर प्रयोग गरें, र त्यसपछि अनफर्म्याट गरिएको मितिबाट वर्ष निकाल्न एक्सेल पार्सर प्रयोग गरें। यदि दुबै मानहरू 4 वर्षमा भिन्न भए, तब मलाई थाहा थियो कि म epoch-1904 सँग प्रणाली प्रयोग गरिरहेको छु।

मैले ढाँचाबद्ध मितिहरू किन प्रयोग गरेन? किनभने जुलाई 5, 1998 लाई हराएको महिनाको दिनको साथ "जुलाई, 98" को रूपमा फर्म्याट गर्न सकिन्छ। हामीले धेरै कम्पनीहरूबाट तालिकाहरू प्राप्त गर्यौं जसले तिनीहरूलाई धेरै फरक तरिकामा सिर्जना गर्‍यो कि मितिहरू पत्ता लगाउन यो हामीमा निर्भर थियो (यस अवस्थामा, म)। यसबाहेक, यदि एक्सेलले यसलाई सही गर्छ भने, त्यसोभए हामीले पनि गर्नुपर्छ!

उही समयमा मैले 39082 सामना गरें। म तपाईंलाई सम्झना गराउन चाहन्छु कि लोटस 1-2-3 ले 1900 लाई एक लीप वर्ष मानेको थियो, र यो विश्वासपूर्वक Excel मा दोहोर्याइएको थियो। र यो वर्ष 1900 मा एक दिन थपिएको हुनाले, धेरै मिति गणना कार्यहरू त्यही दिनको लागि गलत हुन सक्छ। अर्थात्, 39082 जनवरी 1, 2011 (म्याकमा) वा डिसेम्बर 31, 2006 (विन्डोजमा) हुन सक्छ। यदि मेरो "वर्ष पार्सर" ले ढाँचा गरिएको मानबाट 2011 साल निकाल्यो भने, त्यसपछि सबै ठीक छ। तर एक्सेल पार्सरले कुन युग प्रयोग भइरहेको छ भन्ने थाहा नभएकोले, यो पूर्वनिर्धारित रूपमा epoch-1900, वर्ष 2006 मा फर्किन्छ। मेरो आवेदनले फरक 5 वर्ष भएको देख्यो, यसलाई त्रुटि मान्यो, लग इन गर्‍यो, र एक असंबद्ध मान फिर्ता गर्यो।

यसको वरिपरि प्राप्त गर्न, मैले यो लेखे (स्यूडोकोड):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

र त्यसपछि सबै 40 मितिहरू सही रूपमा पार्स गरियो।

ठूला प्रिन्ट कार्यहरूको बीचमा

1980 को प्रारम्भमा, मेरो बुबाले भण्डारण टेक्नोलोजीमा काम गर्नुभयो, जुन अहिले बन्द भएको डिभिजनले टेप ड्राइभ र उच्च-स्पीड टेप फिडिङको लागि वायवीय प्रणालीहरू सिर्जना गर्यो।

तिनीहरूले ड्राइभहरूलाई पुन: डिजाइन गरे ताकि तिनीहरूसँग एउटा केन्द्रीय "A" ड्राइभ सात "B" ड्राइभहरूमा जडान हुन सकियोस्, र "A" ड्राइभलाई नियन्त्रण गर्ने RAM मा रहेको सानो OS ले सबै "B" ड्राइभहरूमा पढ्न र लेखन कार्यहरू प्रत्यायोजित गर्न सकियोस्।

प्रत्येक पटक ड्राइभ "A" सुरु गरिएको थियो, अपरेटिङ सिस्टमलाई यसको मेमोरीमा लोड गर्न "A" मा जडान गरिएको परिधीय ड्राइभमा फ्लपी डिस्क घुसाउन आवश्यक थियो। यो अत्यन्तै आदिम थियो: कम्प्युटिङ पावर 8-बिट माइक्रोकन्ट्रोलर द्वारा प्रदान गरिएको थियो।

त्यस्ता उपकरणहरूको लागि लक्षित दर्शकहरू धेरै ठूला डाटा गोदामहरू भएका कम्पनीहरू थिए - बैंकहरू, खुद्रा चेनहरू, इत्यादि - जसलाई धेरै ठेगाना लेबलहरू वा बैंक स्टेटमेन्टहरू प्रिन्ट गर्न आवश्यक थियो।

एक ग्राहकलाई समस्या थियो। प्रिन्ट कार्यको बीचमा, एउटा विशेष ड्राइभ "A" ले काम गर्न बन्द गर्न सक्छ, जसले गर्दा सम्पूर्ण काम ठप्प हुन सक्छ। ड्राइभको अपरेशन पुनर्स्थापना गर्न, स्टाफले सबै कुरा रिबुट गर्नुपर्‍यो। र यदि यो छ-घण्टा कार्यको बीचमा भयो भने, त्यसपछि महँगो कम्प्युटर समयको ठूलो मात्रा हराएको थियो र सम्पूर्ण सञ्चालनको तालिका अवरुद्ध भयो।

स्टोरेज टेक्नोलोजीबाट प्राविधिकहरू पठाइयो। तर तिनीहरूको उत्कृष्ट प्रयासहरूको बावजुद, तिनीहरू परीक्षण परिस्थितिहरूमा बग पुन: उत्पादन गर्न असमर्थ थिए: यो ठूला मुद्रण कार्यहरूको बीचमा देखा पर्‍यो। समस्या हार्डवेयरको थिएन, उनीहरूले आफूले गर्न सक्ने सबै चीजहरू प्रतिस्थापन गरे: RAM, माइक्रोकन्ट्रोलर, फ्लपी ड्राइभ, टेप ड्राइभको प्रत्येक कल्पनायोग्य भाग - समस्या जारी रह्यो।

त्यसपछि प्राविधिकहरूले हेडक्वार्टरमा बोलाए र विशेषज्ञ बोलाए।

विज्ञले एउटा कुर्सी र एक कप कफी समातेर कम्प्युटर कोठामा बसे—त्यतिबेला त्यहाँ कम्प्युटरका लागि समर्पित कोठाहरू थिए—र कर्मचारीहरूले ठूलो छापाको कामलाई लामबद्ध गरेको हेरे। विशेषज्ञ असफलताको लागि पर्खिरहेका थिए - र यो भयो। सबैले एक्सपर्टलाई हेरे, तर यो किन भयो भन्ने उनलाई थाहा थिएन। त्यसैले उनले कामलाई फेरि लामबद्ध गर्न आदेश दिए, र सबै कर्मचारी र प्राविधिकहरू काममा फर्किए।

विशेषज्ञ फेरि कुर्सीमा बसे र असफलताको लागि पर्खन थाले। करिब छ घण्टा बित्यो र असफलता भयो। विशेषज्ञसँग फेरि कुनै विचार थिएन, बाहेक सबै कुरा मानिसहरूले भरिएको कोठामा भयो। उसले मिशनलाई पुन: सुरु गर्न आदेश दियो, फिर्ता बस्यो र पर्खियो।

तेस्रो असफलता द्वारा, विशेषज्ञले केहि याद गरे। असफलता भयो जब कर्मचारीहरूले विदेशी ड्राइभमा टेप परिवर्तन गरे। यसबाहेक, एक कर्मचारी भुइँमा एक निश्चित टाइल मार्फत हिंड्ने बित्तिकै विफलता भयो।

उठेको भुइँ ६ देखि ८ इन्चको उचाइमा राखिएको आल्मुनियम टाइल्सबाट बनेको थियो। कम्प्यूटरका धेरै तारहरू माथिल्लो भुइँ मुनि दौडिए जसले कसैलाई गल्तिले महत्त्वपूर्ण केबलमा पाइला नपरोस्। माथिल्लो भुइँमा फोहोर आउन नदिन टाइलहरू एकदमै कडासँग राखिएको थियो।

विज्ञले एउटा टाईल विकृत भएको महसुस गरे। जब एक कर्मचारीले यसको कुनामा पाइला राख्यो, टाइलको किनाराहरू छेउछाउको टाइलहरू विरुद्ध रग्यो। टाईलहरू जडान गर्ने प्लास्टिकका भागहरू पनि तिनीहरूसँग घिसिए, जसले स्थिर माइक्रोडिस्चार्जहरू निम्त्यायो जसले रेडियो फ्रिक्वेन्सी हस्तक्षेप सिर्जना गर्‍यो।

आज, RAM रेडियो फ्रिक्वेन्सी हस्तक्षेपबाट धेरै राम्रो सुरक्षित छ। तर ती वर्षहरूमा यो अवस्था थिएन। विशेषज्ञले महसुस गरे कि यो हस्तक्षेपले मेमोरीलाई बाधा पुर्यायो, र यसको साथ अपरेटिङ सिस्टमको सञ्चालन। उहाँले समर्थन सेवालाई कल गर्नुभयो, नयाँ टाइलहरू अर्डर गर्नुभयो, तिनीहरूलाई आफैं स्थापना गर्नुभयो, र समस्या गायब भयो।

यो उच्च ज्वार हो!

कथा सर्भर कोठामा भएको थियो, पोर्ट्समाउथ (मलाई लाग्छ), डक्स क्षेत्रमा अफिसको चौथो वा पाँचौं तलामा।

एक दिन मुख्य डाटाबेसको साथ युनिक्स सर्भर क्र्यास भयो। तिनीहरूले उसलाई रिबुट गरे, तर ऊ खुसीसाथ बारम्बार झर्दै गयो। हामीले समर्थन सेवाबाट कसैलाई कल गर्ने निर्णय गर्यौं।

सहयोगी मान्छे... मलाई लाग्छ उसको नाम मार्क थियो, तर यसले फरक पर्दैन... मलाई लाग्दैन कि म उसलाई चिन्छु। केही फरक पर्दैन, साँच्चै। मार्क संग टाँसौं, ठीक छ? महान।

त्यसोभए, केहि घण्टा पछि मार्क आइपुग्यो (यो लीड्स देखि पोर्ट्समाउथ सम्म लामो बाटो छैन, तपाईलाई थाहा छ), सर्भर खोलियो र सबै कुरा बिना समस्या काम गर्यो। सामान्य धिक्कार समर्थन, ग्राहक यस बारे धेरै निराश हुन्छ। मार्कले लग फाइलहरू हेर्छ र कुनै पनि अप्रिय कुरा फेला पार्दैन। त्यसोभए मार्क ट्रेनमा फर्किन्छ (वा जुनसुकै ढुवानी मोडमा ऊ आइपुग्यो, यो मलाई थाहा छ सबैको लागि लङ्गडा गाई हुन सक्छ ... जे भए पनि, यसले फरक पार्दैन, ठीक छ?) र खेर गएर लीड्स फर्कन्छ। दिन।

त्यही साँझ फेरि सर्भर क्र्यास भयो। कथा उस्तै छ... सर्भर उठ्दैन। मार्कले टाढाबाट मद्दत गर्ने प्रयास गर्छ, तर ग्राहकले सर्भर सुरु गर्न सक्दैन।

अर्को रेल, बस, लेमन मेरिन्गु वा केहि अन्य बकवास, र मार्क पोर्ट्समाउथमा फिर्ता छ। हेर्नुहोस्, सर्भर कुनै समस्या बिना बुट! चमत्कार। मार्कले अपरेटिङ सिस्टम वा सफ्टवेयरसँग सबै कुरा ठीक छ भनी जाँच गर्न धेरै घण्टा बिताउँछ र लीड्सको लागि प्रस्थान गर्छ।

दिनको बीचमा सर्भर क्र्यास हुन्छ (सजिलो लिनुहोस्!) यस पटक सर्भर प्रतिस्थापन गर्न हार्डवेयर समर्थन व्यक्तिहरू ल्याउनु उचित देखिन्छ। तर होइन, लगभग 10 घण्टा पछि यो पनि खस्छ।

त्यो अवस्था केही दिनसम्म दोहोरियो । सर्भरले काम गर्छ, लगभग 10 घण्टा पछि क्र्यास हुन्छ र अर्को 2 घण्टाको लागि सुरु हुँदैन। तिनीहरूले चिसो जाँच गरे, मेमोरी लीक गरे, तिनीहरूले सबै कुरा जाँच गरे, तर केही फेला पारेनन्। त्यसपछि दुर्घटना रोकियो।

साता बेवारिसे बित्यो...सबै खुशी थिए। यो सबै फेरि सुरु नभएसम्म खुसी। तस्वीर उस्तै छ। १० घण्टा काम, २-३ घण्टा डाउनटाइम...

र त्यसपछि कसैले (मलाई लाग्छ कि उनीहरूले मलाई भने कि यो व्यक्तिको आईटीसँग कुनै सरोकार छैन) भने:

"यो ज्वार हो!"

विस्मयादिबोधक खाली नजरले भेटियो, र कसैको हात सायद सुरक्षा कल बटनमा हिचकिचायो।

"यो ज्वार संग काम रोक्छ।"

यो आईटी समर्थन कार्यकर्ताहरूको लागि पूर्ण रूपमा विदेशी अवधारणा जस्तो देखिन्छ, जो कफीको लागि बस्दा टाइड इयरबुक पढ्ने सम्भावना छैन। उनीहरूले यो कुनै पनि हिसाबले ज्वारभाटासँग सम्बन्धित हुन नसक्ने बताए, किनभने सर्भर असफल बिना एक हप्तादेखि काम गरिरहेको थियो।

"गत हप्ता ज्वार कम थियो, तर यो हप्ता यो उच्च छ।"

याट लाइसेन्स नभएकाहरूको लागि सानो शब्दावली। ज्वारभाटा चन्द्र चक्र मा निर्भर गर्दछ। र जब पृथ्वी घुम्छ, प्रत्येक 12,5 घण्टामा सूर्य र चन्द्रमाको गुरुत्वाकर्षण तानले ज्वारीय लहर सिर्जना गर्दछ। 12,5-घण्टा चक्रको सुरुमा त्यहाँ उच्च ज्वार छ, चक्रको बीचमा त्यहाँ एक भाटा हुन्छ, र अन्त्यमा फेरि उच्च ज्वार छ। तर जसरी चन्द्रमाको परिक्रमा परिवर्तन हुन्छ, त्यसैगरी कम र उच्च ज्वारबीचको भिन्नता पनि हुन्छ। जब चन्द्रमा सूर्य र पृथ्वीको बीचमा हुन्छ वा पृथ्वीको विपरित छेउमा हुन्छ (पूर्ण चन्द्रमा वा कुनै चन्द्रमा छैन), हामीले सिजिगिन टाइडहरू पाउँछौं - उच्चतम उच्च ज्वार र सबैभन्दा कम तल्लो ज्वार। आधा चन्द्रमामा हामीले चतुर्भुज ज्वार पाउँछौं - सबैभन्दा तल्लो ज्वार। दुई चरम सीमाहरू बीचको भिन्नता धेरै कम हुन्छ। चन्द्र चक्र 28 दिन सम्म रहन्छ: syzygian - quadrature - syzygian - quadrature।

जब प्राविधिकहरूलाई ज्वार बलहरूको सार बुझाइयो, उनीहरूले तुरुन्तै सोचे कि उनीहरूले पुलिसलाई बोलाउन आवश्यक छ। र एकदम तार्किक। तर यो केटा सही थियो बाहिर जान्छ। दुई हप्ता अघि, एक विनाशक कार्यालयबाट टाढा थिएन। प्रत्येक चोटि जब ज्वारले यसलाई निश्चित उचाइमा उठायो, जहाजको राडार पोष्ट सर्भर कोठाको भुइँको स्तरमा समाप्त भयो। र रडार (वा इलेक्ट्रोनिक युद्ध उपकरण, वा केहि अन्य सैन्य खेलौना) ले कम्प्युटरहरूमा अराजकता सिर्जना गर्यो।

रकेटको लागि उडान मिशन

मलाई अपरेटिङ सिस्टम, कम्पाइलर र भाषाको नयाँ संस्करणहरूमा ठूलो (लगभग 400 हजार लाइनहरू) रकेट प्रक्षेपण नियन्त्रण र निगरानी प्रणाली पोर्ट गर्ने काम दिइएको थियो। अझ स्पष्ट रूपमा, सोलारिस 2.5.1 देखि सोलारिस 7 सम्म, र Ada 83 मा लेखिएको Verdix Ada विकास प्रणाली (VADS), Ada 95 मा लेखिएको Rational Apex Ada प्रणाली सम्म। VADS Rational द्वारा खरिद गरिएको थियो, र यसको उत्पादन थियो। अप्रचलित, यद्यपि Rational ले एपेक्स कम्पाइलरमा संक्रमण सहज बनाउन VADS-विशेष प्याकेजहरूको मिल्दो संस्करणहरू लागू गर्ने प्रयास गर्यो।

तीन व्यक्तिले मलाई कोड सफासँग कम्पाइल गर्न मद्दत गरे। दुई हप्ता लाग्यो। र त्यसपछि मैले प्रणालीलाई काम गर्न आफैले काम गरे। छोटकरीमा, मैले सामना गरेको सफ्टवेयर प्रणालीको यो सबैभन्दा खराब वास्तुकला र कार्यान्वयन थियो, त्यसैले पोर्ट पूरा गर्न अर्को दुई महिना लाग्यो। त्यसपछि प्रणाली परीक्षणको लागि पेश गरिएको थियो, जसमा धेरै महिना लाग्यो। मैले परीक्षणको क्रममा फेला परेका बगहरू तुरुन्तै सच्याएँ, तर तिनीहरूको संख्या चाँडै घट्यो (स्रोत कोड उत्पादन प्रणाली थियो, त्यसैले यसको कार्यक्षमताले भरपर्दो काम गर्‍यो, मैले नयाँ कम्पाइलरमा अनुकूलनको क्रममा उत्पन्न भएका बगहरू हटाउनुपर्‍यो)। अन्ततः, जब सबै कुरा जसरी काम गरिरहेको थियो, मलाई अर्को परियोजनामा ​​स्थानान्तरण गरियो।

र थ्यान्क्सगिभिङको अघिल्लो शुक्रबार फोनको घण्टी बज्यो।

रकेट प्रक्षेपण लगभग तीन हप्तामा परीक्षण गरिनु पर्ने थियो, र काउन्टडाउनको प्रयोगशाला परीक्षणको क्रममा, आदेशहरूको अनुक्रम अवरुद्ध गरिएको थियो। वास्तविक जीवनमा, यसले परीक्षण रद्द गर्नेछ, र यदि इन्जिन सुरु भएको केही सेकेन्डमा अवरोध उत्पन्न भयो भने, सहायक प्रणालीहरूमा धेरै अपरिवर्तनीय कार्यहरू हुनेछन्, जसका लागि रकेटको लामो - र महँगो - तयारी आवश्यक पर्दछ। यो सुरु भएको थिएन, तर धेरै मानिसहरू धेरै समय र धेरै, धेरै पैसाको हानिको बारेमा धेरै चिन्तित हुने थिए। रक्षा विभागले लापरवाही पैसा खर्च गर्छ भनेर कसैलाई नभन्नुहोस्—मैले कुनै पनि ठेक्का प्रबन्धकलाई भेटेको छैन जसले बजेट पहिलो वा दोस्रो, तालिका अनुसार राखेको छैन।

अघिल्ला महिनाहरूमा, यो काउन्टडाउन चुनौती धेरै भिन्नताहरूमा सयौं पटक चलाइएको थियो, केवल केही सानो हिचकीहरू। त्यसोभए यो हुने सम्भावना धेरै कम थियो, तर यसको परिणाम धेरै महत्त्वपूर्ण थियो। यी दुबै कारकहरूलाई गुणा गर्नुहोस्, र तपाईंले बुझ्नुहुनेछ कि समाचारले मेरो र दर्जनौं इन्जिनियरहरू र प्रबन्धकहरूको लागि बिदाको हप्ता बर्बाद हुने भविष्यवाणी गरेको छ।

र प्रणाली पोर्ट गर्ने व्यक्तिको रूपमा मलाई ध्यान दिइयो।

धेरैजसो सुरक्षा-महत्वपूर्ण प्रणालीहरूमा जस्तै, धेरै प्यारामिटरहरू लग गरिएका थिए, त्यसैले प्रणाली क्र्यास हुनु अघि कार्यान्वयन गरिएका कोडका केही लाइनहरू पहिचान गर्न एकदमै सजिलो थियो। र निस्सन्देह, त्यहाँ तिनीहरूको बारेमा केहि असामान्य थिएन; उही अभिव्यक्तिहरू सफलतापूर्वक शाब्दिक रूपमा हजारौं पटक एउटै दौडको समयमा कार्यान्वयन गरिएको थियो।

हामीले एपेक्सबाट मानिसहरूलाई तर्कसंगतमा बोलायौं किनभने उनीहरूले कम्पाइलर विकास गरेका थिए र उनीहरूले विकास गरेका केही दिनचर्याहरू शंकास्पद कोडमा बोलाइएका थिए। तिनीहरू (र अरू सबै) शाब्दिक रूपमा राष्ट्रिय महत्त्वको समस्याको जरासम्म पुग्न आवश्यक छ भनेर प्रभावित भए।

पत्रिकाहरूमा केही रोचक नरहेकोले, हामीले स्थानीय प्रयोगशालामा समस्या पुन: उत्पादन गर्ने प्रयास गर्ने निर्णय गर्यौं। यो कुनै सजिलो काम थिएन किनभने घटना प्रति 1000 रन लगभग एक पटक भयो। एउटा संदिग्ध कारण भनेको विक्रेता-विकसित म्युटेक्स प्रकार्य (VADS माइग्रेसन प्याकेजको अंश) मा कल गरिएको थियो। Unlock ताला खोल्न नेतृत्व गरेन। प्रशोधन थ्रेड जसले फंक्शनलाई प्रशोधित हृदयघात सन्देशहरू भनिन्छ, जुन नाममात्र प्रत्येक सेकेन्डमा आइपुग्छ। हामीले फ्रिक्वेन्सीलाई १० हर्ट्जमा बढायौं, अर्थात् प्रति सेकेन्ड १० पटक, र दौडन थाल्यौं। करिब एक घण्टा पछि प्रणाली आफैं लक भयो। लगमा, हामीले देख्यौं कि रेकर्ड गरिएका सन्देशहरूको क्रम असफल परीक्षणको समयमा जस्तै थियो। हामीले धेरै रनहरू बनायौं, प्रणाली सुरु भएको 10-10 मिनेट पछि लगातार अवरुद्ध भयो, र प्रत्येक पटक लगमा उही मार्ग समावेश थियो। यद्यपि हामीले प्राविधिक रूपमा फरक कोड चलाउँदै थियौं - सन्देश फ्रिक्वेन्सी फरक थियो - प्रणालीको व्यवहार उस्तै थियो, त्यसैले हामी विश्वस्त थियौं कि यो लोड परिदृश्यले समान समस्या निम्त्याउँदैछ।

अब हामीले अभिव्यक्तिको अनुक्रममा अवरुद्ध कहाँ भयो भनेर पत्ता लगाउन आवश्यक छ।

प्रणालीको यो कार्यान्वयनले Ada कार्य प्रणाली प्रयोग गर्‍यो, र यसलाई अविश्वसनीय रूपमा खराब रूपमा प्रयोग गर्‍यो। कार्यहरू Ada मा एकैसाथ कार्यान्वयन गर्न मिल्ने उच्च-स्तरीय निर्माण हो, कार्यान्वयनको थ्रेडहरू जस्तै, भाषामा मात्र निर्मित। जब दुई कार्यहरू संवाद गर्न आवश्यक छ, तिनीहरूले "एक भेटघाट सेट गर्नुहोस्", आवश्यक डाटा आदान प्रदान गर्नुहोस्, र त्यसपछि भेटघाट रोक्नुहोस् र तिनीहरूको स्वतन्त्र कार्यान्वयनमा फर्कनुहोस्। तर, प्रणाली फरक ढंगले लागू भयो। एक लक्ष्य कार्य संगठित भएपछि, त्यो लक्ष्य कार्य अर्को कार्य संग संगठित भयो, जुन त्यसपछि तेस्रो कार्य संग संगठित भयो, र केहि प्रक्रिया पूरा नभए सम्म। यस पछि, यी सबै भेटघाट पूरा भयो र प्रत्येक कार्य आफ्नो कार्यान्वयनमा फर्किनु पर्यो। त्यो हो, हामीले संसारको सबैभन्दा महँगो प्रकार्य कल प्रणालीसँग काम गरिरहेका थियौं, जसले सम्पूर्ण "मल्टीटास्किङ" प्रक्रियालाई रोकेको थियो जब यसले इनपुट डेटाको अंशलाई प्रशोधन गर्छ। र यो भन्दा पहिले समस्याहरू निम्त्याउँदैन किनभने थ्रुपुट धेरै कम थियो।

मैले यो कार्य संयन्त्रको वर्णन गरेको छु किनभने जब भेट अनुरोध गरिएको थियो वा पूरा हुने अपेक्षा गरिएको थियो, "कार्य स्विच" हुन सक्छ। त्यो हो, प्रोसेसरले अर्को कार्य प्रशोधन सुरु गर्न सक्छ जुन कार्यान्वयन गर्न तयार छ। यो बाहिर जान्छ कि जब एक कार्य अर्को कार्य संग मिलन को लागी तयार छ, एक पूर्ण फरक कार्य कार्यान्वयन सुरु गर्न सक्छ, र अन्ततः नियन्त्रण पहिलो मिलन मा फर्किन्छ। र अन्य घटनाहरू हुन सक्छ जसले कार्यलाई स्विच गर्नको कारण बनाउँछ; एउटा यस्तो घटना प्रणाली प्रकार्यको लागि कल हो, जस्तै मुद्रण वा mutex कार्यान्वयन।

कुन लाइनको कोडले समस्या निम्त्याइरहेको थियो भनेर बुझ्नको लागि, मैले कार्य स्विच ट्रिगर नगरी कथनहरूको अनुक्रम मार्फत प्रगति रेकर्ड गर्ने तरिका खोज्नु आवश्यक थियो, जसले दुर्घटना हुनबाट रोक्न सक्छ। त्यसैले फाइदा उठाउन सकिन Put_Line()I/O कार्यहरू गर्नबाट बच्न। म काउन्टर चर वा यस्तै केहि सेट गर्न सक्छु, तर यदि मैले यसलाई स्क्रिनमा प्रदर्शन गर्न सक्दिन भने म कसरी यसको मूल्य देख्न सक्छु?

साथै, लग जाँच गर्दा, यो पत्ता लाग्यो कि, मुटुको धड्कन सन्देशहरूको प्रशोधनमा फ्रिजको बावजुद, जसले प्रक्रियाको सबै I/O अपरेसनहरू अवरुद्ध गर्यो र अन्य प्रशोधनलाई प्रदर्शन हुनबाट रोक्यो, अन्य स्वतन्त्र कार्यहरू कार्यान्वयन गर्न जारी रह्यो। त्यो हो, काम पूर्ण रूपमा अवरुद्ध गरिएको थिएन, केवल कार्यहरूको (महत्वपूर्ण) श्रृंखला।

यो अवरुद्ध अभिव्यक्ति मूल्याङ्कन गर्न आवश्यक सुराग थियो।

मैले एउटा Ada प्याकेज बनाएको छु जसमा एउटा कार्य, एक गणना गरिएको प्रकार, र त्यस प्रकारको विश्वव्यापी चर समावेश छ। संख्यात्मक शाब्दिकहरू समस्याग्रस्त अनुक्रमको विशिष्ट अभिव्यक्तिहरूमा बाध्य थिए (जस्तै। Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), र त्यसपछि यसमा असाइनमेन्ट अभिव्यक्तिहरू सम्मिलित गरियो जसले विश्वव्यापी भ्यारीएबलमा सम्बन्धित गणना तोक्यो। यी सबैको वस्तु कोडले मेमोरीमा एक स्थिर भण्डारण गरेको हुनाले, यसको कार्यान्वयनको परिणामको रूपमा कार्य स्विचिङ अत्यन्तै असम्भव थियो। हामी मुख्य रूपमा कार्य स्विच गर्न सक्ने अभिव्यक्तिहरूमा शंकास्पद थियौं, किनकि कार्यलाई फिर्ता स्विच गर्दा (धेरै कारणहरूका लागि) फर्किनुको सट्टा कार्यान्वयनमा रोक लगाइएको थियो।

ट्र्याकिङ कार्य केवल एक लूप मा दौडियो र ग्लोबल चर को मान परिवर्तन भएको छ कि छैन भनेर आवधिक रूपमा जाँच गरियो। प्रत्येक परिवर्तनको साथ, मान फाइलमा बचत गरिएको थियो। त्यसपछि छोटो प्रतीक्षा र नयाँ जाँच। मैले फाइलमा भ्यारीएबल लेखेको थिएँ किनभने समस्या क्षेत्रमा कार्य स्विच गर्दा प्रणालीले कार्यान्वयनको लागि चयन गर्दा मात्र कार्य कार्यान्वयन भएको थियो। यस कार्यमा जे भयो त्यसले अन्य, असंबद्ध अवरुद्ध कार्यहरूलाई असर गर्दैन।

यो अपेक्षा गरिएको थियो कि जब प्रणाली समस्याग्रस्त कोड कार्यान्वयन गर्ने बिन्दुमा पुग्यो, प्रत्येक अर्को अभिव्यक्तिमा सार्दा ग्लोबल चर रिसेट हुनेछ। त्यसोभए केहि हुनेछ जसले कार्यलाई स्विच गर्नको लागि कारण बनाउँछ, र यसको कार्यान्वयन फ्रिक्वेन्सी (10 हर्ट्ज) अनुगमन कार्यको भन्दा कम छ, मोनिटरले ग्लोबल चरको मूल्य कब्जा गर्न सक्छ र यसलाई लेख्न सक्छ। सामान्य अवस्थामा, मैले गणनाको सबसेटको दोहोरिने क्रम प्राप्त गर्न सक्छु: कार्य स्विचको समयमा चलको अन्तिम मानहरू। ह्याङ्गिङ गर्दा, ग्लोबल चर अब परिवर्तन हुँदैन, र लेखिएको अन्तिम मानले कुन अभिव्यक्ति पूरा नभएको संकेत गर्दछ।

मैले ट्र्याकिङको साथ कोड चलाएँ। ऊ जम्यो। र अनुगमनले घडीको काम जस्तै काम गर्यो।

लगमा अपेक्षित अनुक्रम समावेश थियो, जुन म्युटेक्स कल भएको जनाउने मानले अवरोध गरेको थियो। Unlock, र कार्य पूरा भएको छैन - जस्तै हजारौं अघिल्लो कलहरूको मामला हो।

एपेक्स इन्जिनियरहरूले यस समयमा आफ्नो कोडको ज्वरोका साथ विश्लेषण गरिरहेका थिए र म्युटेक्समा एउटा ठाउँ भेट्टाए जहाँ, सैद्धान्तिक रूपमा, लक हुन सक्छ। तर यसको सम्भाव्यता एकदमै कम थियो, किनकि कुनै निश्चित समयमा हुने घटनाहरूको निश्चित क्रमले मात्र रोक लगाउन सक्छ। मर्फीको कानून, साथीहरू, यो मर्फीको कानून हो।

मलाई चाहिने कोडको टुक्राको सुरक्षा गर्न, मैले म्युटेक्स फंक्शन कलहरू (OS म्युटेक्स कार्यक्षमताको शीर्षमा निर्मित) लाई त्यो टुक्रामा म्युटेक्स पहुँच नियन्त्रण गर्न सानो नेटिभ Ada mutex प्याकेजको साथ प्रतिस्थापन गरें।

मैले यसलाई कोडमा घुसाएँ र परीक्षण चलाएँ। सात घण्टा पछि कोड अझै काम गरिरहेको थियो।

मेरो कोड Rational मा पेश गरिएको थियो, जहाँ तिनीहरूले यसलाई कम्पाइल गरे, यसलाई छुट्याए, र जाँच गरे कि यसले समस्याग्रस्त mutex प्रकार्यहरूमा प्रयोग गरिएको उही दृष्टिकोण प्रयोग गर्दैन।

यो मेरो क्यारियरको सबैभन्दा भीड कोड समीक्षा थियो 🙂 मसँग कोठामा करिब दस इन्जिनियरहरू र प्रबन्धकहरू थिए, अरू दस व्यक्तिहरू सम्मेलन कलमा थिए - र तिनीहरू सबैले करिब २० लाइनको कोड जाँच गरे।

कोड समीक्षा गरियो, नयाँ कार्यान्वयनयोग्य फाइलहरू भेला गरियो र औपचारिक रिग्रेसन परीक्षणको लागि पेश गरियो। केही हप्ता पछि, काउन्टडाउन परीक्षण सफल भयो र रकेट उड्यो।

ठीक छ, यो सबै राम्रो र राम्रो छ, तर कथाको बिन्दु के हो?

यो एक बिल्कुल घृणित समस्या थियो। कोडका सयौं हजार लाइनहरू, समानान्तर कार्यान्वयन, एक दर्जनभन्दा बढी अन्तरक्रिया गर्ने प्रक्रियाहरू, कमजोर वास्तुकला र कमजोर कार्यान्वयन, इम्बेडेड प्रणालीहरूको लागि इन्टरफेसहरू र लाखौं डलर खर्च गरियो। कुनै दबाब छैन, ठीक छ।

यस समस्यामा काम गर्ने म एक्लै थिइनँ, यद्यपि म स्पटलाइटमा थिएँ किनकि म पोर्टिङ गरिरहेको थिएँ। तर मैले गरे पनि, यसको मतलब यो होइन कि मैले कोडका सबै सयौं हजार लाइनहरू बुझें, वा तिनीहरूलाई स्किम गरें। कोड र लगहरू देशभरका इन्जिनियरहरूद्वारा विश्लेषण गरिएको थियो, तर जब तिनीहरूले मलाई असफलताको कारणहरूको बारेमा आफ्नो परिकल्पनाहरू भने, मलाई तिनीहरूलाई खण्डन गर्न आधा मिनेट मात्र लाग्यो। र जब मलाई सिद्धान्तहरू विश्लेषण गर्न भनियो, म यसलाई अरू कसैलाई हस्तान्तरण गर्नेछु, किनभने यो मलाई स्पष्ट थियो कि यी इन्जिनियरहरू गलत बाटोमा गइरहेका थिए। ध्वनि अभिमान? हो, यो सत्य हो, तर मैले परिकल्पनाहरू र अनुरोधहरूलाई अर्को कारणले अस्वीकार गरें।

मैले समस्याको प्रकृति बुझें। मलाई ठ्याक्कै थाहा थिएन कि यो कहाँ भइरहेको थियो वा किन, तर मलाई थाहा थियो के भइरहेको थियो।

वर्षौंको दौडान, मैले धेरै ज्ञान र अनुभव संकलन गरेको छु। म एडा प्रयोग गर्ने अग्रगामी मध्ये एक थिएँ र यसको फाइदा र बेफाइदा बुझेको थिएँ। मलाई थाहा छ कि कसरी Ada रनटाइम पुस्तकालयहरूले कार्यहरू ह्यान्डल गर्छन् र समानान्तर कार्यान्वयनसँग व्यवहार गर्छन्। र म मेमोरी, रेजिस्टर र एसेम्बलरको स्तरमा निम्न-स्तरको प्रोग्रामिङ बुझ्छु। अर्को शब्दमा, मसँग मेरो क्षेत्रमा गहिरो ज्ञान छ। र मैले तिनीहरूलाई समस्याको कारण पत्ता लगाउन प्रयोग गरें। मैले बगको वरिपरि मात्र काम गरेन, मैले यसलाई धेरै संवेदनशील रनटाइम वातावरणमा कसरी फेला पार्ने भनेर बुझें।

संहितासँगको सङ्घर्षका यस्ता कथाहरू त्यस्ता सङ्घर्षका विशेषताहरू र अवस्थाहरूसँग परिचित नभएकाहरूका लागि धेरै रोचक छैनन्। तर यी कथाहरूले हामीलाई वास्तवमै कठिन समस्याहरू समाधान गर्न के लिन्छ भनेर बुझ्न मद्दत गर्दछ।

साँच्चै कठिन समस्याहरू समाधान गर्न, तपाइँ केवल एक प्रोग्रामर भन्दा बढी हुन आवश्यक छ। तपाईंले कोडको "भाग्य" बुझ्न आवश्यक छ, यसले कसरी यसको वातावरणसँग अन्तरक्रिया गर्छ, र वातावरण आफैले कसरी काम गर्दछ।

र त्यसपछि तपाइँसँग तपाइँको आफ्नै बर्बाद छुट्टी हप्ता हुनेछ।

फेरि जारी राखौंला।

स्रोत: www.habr.com