मूल: लेख " अंतरिक्ष में दुर्घटनाओं से एक डेवलपर के रूप में मैंने क्या सीखा ", एविल मार्टियंस ब्लॉग " मार्टन क्रॉनिकल्स " से आंद्रेई सीटनिक द्वारा।

PostCSS और AutoPrefixer की लेखिका आंद्रेई सीटनिक ने सोवियत संघ द्वारा अंतरिक्ष अन्वेषण से संबंधित कहानियों का चयन किया। आप सीखेंगे कि ओपन-सोर्स आंदोलन में एक डेवलपर और प्रतिभागी के रूप में बढ़ने के लिए आंद्रेई ने उनसे क्या सबक सीखा है। असफल डॉकिंग, वातावरण में नाटकीय प्रवेश और स्पेसशिप के बीच रेल के साथ एक अनूठा संक्रमण - आधुनिक वेब विकास के साथ यह सब क्या करना है? एक पोस्ट में यह सब पढ़ें!

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

हालाँकि रॉकेट लिखना (अधिकांश भाग के लिए) बनाना उतना कठिन नहीं है, फिर भी हम, सॉफ्टवेयर इंजीनियर, अक्सर जटिल सिस्टम बनाने वाली बड़ी टीमों में काम करते हैं। और अंतरिक्ष खोजकर्ता के रूप में, कभी-कभी हम जटिलता के खिलाफ लड़ाई हार जाते हैं।

"एक आपातकालीन शुरुआत हमें दर्जनों सफल लोगों की तुलना में प्रणाली को जानने और सुधारने के लिए बहुत अधिक देती है"

- निकोलाई पिलुगिन, शिक्षाविद, डिजाइनर, रॉकेट और अंतरिक्ष-रॉकेट परिसरों के लिए स्वायत्त नियंत्रण प्रणालियों के क्षेत्र में विशेषज्ञ।

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

पहला पाठ: कभी भी उपयोगकर्ताओं को दोष न दें *

* ... और उनकी प्रत्येक अपील में बदलाव करें।

1960 के दशक के उत्तरार्ध में, संयुक्त राज्य अमेरिका और यूएसएसआर ने नई पीढ़ी के अंतरिक्ष यान पर काम पूरा किया। प्रयोगात्मक बुध / मिथुन और पूर्व / सूर्योदय के बाद अपोलो और संघ एक बड़ा कदम था। नए जहाजों को न केवल निकट-पृथ्वी की कक्षाओं में काम करने के लिए डिज़ाइन किया गया था, बल्कि चंद्रमा और वापस जाने वाली उड़ानों के लिए भी।

अक्टूबर 1968 में, यूएसएसआर सोयुज -1 आपदा से उबर गया और एक नया प्रयास करने के लिए तैयार था: पहली बार कक्षा में दो जहाजों के मैनुअल डॉकिंग का प्रदर्शन करने की योजना बनाई गई थी। स्वचालित सोयुज -2 को पहले अंतरिक्ष में जाना चाहिए था। तब सोयुज -3 में जियोर्जी बेरेगोवोई को उसी कक्षा में प्रवेश करना था और जहाजों को डॉक करना था।


सोयुज -4, सोयूज -8 और सोयुज -10 व्लादिमीर शातलोव के पायलट दो जहाजों के डॉकिंग का प्रदर्शन करते हैं।

लॉन्च अच्छा चला। सिर्फ 1.5 घंटे के बाद, सोयुज -3 डॉकिंग दूरी पर था। पैंतरेबाज़ी की योजना "रात" समय के लिए थी, पृथ्वी की छाया में। हालाँकि, मैन्युअल डॉकिंग के सभी प्रयास असफल रूप से समाप्त हुए।

और केवल जब दोनों जहाज दिन की तरफ थे, बेरेगोवोइ ने एक त्रुटि की खोज की: सोयुज -2 को अनुदैर्ध्य अक्ष के साथ 180 डिग्री घुमाया गया था।

उस समय से डॉकिंग प्रयासों के लिए सभी ईंधन आपूर्ति का उपयोग किया गया था, बेरेगोवोई को मिशन पूरा करने और चार दिन बाद पृथ्वी पर लौटने का आदेश दिया गया था। समाचारपत्रों ने उड़ान को सफल कहा, बेरेगोवय को सोवियत संघ के हीरो का खिताब दिया गया और जल्द ही इसे बढ़ावा दिया गया। हालाँकि, इस कहानी से सही सबक सीखे गए थे, और बाद के सभी जोड़ों के लिए नए नियम पेश किए गए थे:

• सनी की तरफ केवल डॉक।
  
• लॉन्च के साथ एक दिन में डॉक करने की योजना न बनाएं, ताकि पायलटों को कक्षा में प्रवेश करने का समय मिल सके।
  

डॉक सोयुज -4 फिल्म "फोर इन स्पेस" ।

जब आप USB टाइप-ए प्लग को फिर से गलत साइड पर डालें तो यह कहानी याद रखें।

कोई बुरा उपयोगकर्ता नहीं है - एक बुरा इंटरफ़ेस है।

उपयोगकर्ताओं को दोष देना आसान है। हालांकि, लोग हमेशा गलत होंगे। डेवलपर्स कोई अपवाद नहीं हैं। ओपन सोर्स आंदोलन में एक भागीदार के रूप में, मुझे एहसास हुआ कि यदि आप डेवलपर्स को गलतियों के लिए दोषी ठहराते हैं, तो यह भविष्य में गलतियों को रोकने में मदद नहीं करेगा।

एक कठोर RTFM- शैली के उत्तर (या इससे भी बदतर, कोई जवाब नहीं!) के साथ अपने ओपनसोर्स रिपॉजिटरी में एक समस्या के बारे में समस्या को बंद करना, आप एक ही मुद्दे की उपस्थिति से खुद की रक्षा नहीं करेंगे। आपको बार-बार वही संदेश प्राप्त होंगे।

PostCSS और ऑटो उपसर्गकर्ता के निर्माता के रूप में, मुझे बहुत सारी समस्या रिपोर्ट मिलती हैं। लंबे समय में समय बर्बाद नहीं करने के लिए, मैं नियम का पालन करता हूं: प्रत्येक समस्या को कोड या प्रलेखन में बदलाव करना चाहिए ।

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

उदाहरण के लिए, कई पोस्टसीएस उपयोगकर्ता पार्सर विकल्प के बारे में भूल जाते हैं और संबंधित पार्सरों के बिना फाइल .cscs को प्रोसेस करने की कोशिश करते हैं। उपयोगकर्ताओं को दोष देने के बजाय, हमने एक छोटी चेतावनी जोड़ी:

if (error.name === 'CssSyntaxError' && opts.from.endsWith('.scss')) {   error.message += '\nYou tried to parse SCSS with ' +                    'the standard CSS parser; ' +                    'try again with the postcss-scss parser' } 

दूसरा सबक: हर तरह से, समस्याओं के बारे में डेवलपर को सूचित करें

सोयूज -2 और सोयुज -3 की उड़ान के तीन महीने बाद, यूएसएसआर मैनुअल डॉकिंग पर एक नए प्रयास के लिए तैयार था, और भी महत्वाकांक्षी।

यह एक दिन के अंतर के साथ दो मानवयुक्त अंतरिक्ष यान को लॉन्च करने की योजना बनाई गई थी: एक अंतरिक्ष यात्री के साथ सोयुज -4 और तीन के साथ सोयुज -5। डॉकिंग के बाद, सोयुज -5 से पायलट इंजीनियर और अनुसंधान इंजीनियर को सोयूज -4 के लिए खुली जगह से गुजरना और पृथ्वी पर वापस जाना था। यही है, उन्होंने एक जहाज में उड़ान भरी, अंतरिक्ष में टहलते हुए, दूसरे जहाज पर उतरे।


सोयुज -5 के बाहरी स्थान से सोयुज -4 तक संक्रमण।

बोरिस वोलिनोव , जो एक सोयुज -5 पायलट था, को अकेले रहना था और एक दिन बाद पृथ्वी पर वापस आना था।

इस बार डॉकिंग सफल रहा, सोयुज -4 ने बिना किसी समस्या के अपना मिशन पूरा किया। और 18 जनवरी, 1969 को घर लौटने और वोलिनोव के लिए समय था। संघ में तीन वियोज्य मॉड्यूल होते हैं, और केवल एक, केंद्रीय एक को वायुमंडल में प्रवेश करने के लिए डिज़ाइन किया गया था।


संघ की योजना। स्रोत: नासा

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

हैच के चारों ओर की सील जलने लगी, लैंडिंग कैप्सूल में जहरीला धुआं भरने लगा। गुरुत्वाकर्षण और वातावरण ने अपना काम किया; डिसेन्सलेस वोलिनोव को एक कुर्सी पर रखा गया।


संघ -4 के वातावरण में प्रवेश की कलात्मक छवि।

हालांकि, वोलेनव को मारने वाली गर्मी अप्रत्याशित रूप से उसे बचा सकती है: साधन मॉड्यूल के ईंधन टैंक में विस्फोट हो गया, और परिणामस्वरूप, यह अलग हो गया। लैंडिंग कैप्सूल सही स्थिति में बदल गया, हीट शील्ड आगे।

इस समय, वोल्नोव ने आश्वस्त किया कि वह अंतिम क्षणों में जी रहा था, उसने वह सब कुछ दर्ज किया जो वह देखता है और सुनता है।

समस्याएं यहीं खत्म नहीं हुईं। पैराशूट स्लिंग उलझ गए, और नरम लैंडिंग इंजन काम नहीं किया। कैप्सूल नियोजित क्षेत्र से बहुत तेज गति से जमीन से टकराया। घायल वोलिनोव को the38 ° C पर ठंड में तब तक जीवित रहना पड़ा जब तक कि बचाव दल उसके पास नहीं पहुँच गए।

अंतरिक्ष यात्री ने हर ध्वनि और कंपन पर जोर से टिप्पणी की, यह उम्मीद करते हुए कि उड़ान रिकॉर्डर दुर्घटनाग्रस्त होने से बचेगा और इंजीनियर रिकॉर्डिंग सुनने और नई आपदाओं को रोकने में सक्षम होंगे।

एक हॉलीवुड फिल्म अनुकूलन के लायक यह कहानी मुझे क्या सिखाती है?

जब भी मुझे लाइब्रेरी या डेवलपमेंट टूल से जुड़ी कोई समस्या आती है, मुझे बोरिस वोलिनोव की याद आती है। यदि वह मृत्यु के कगार पर भी समस्याओं की रिपोर्ट करने में सक्षम था, तो मुझे डेवलपर को रिपोर्ट भेजने में कुछ मिनट लग सकते हैं।

यहां तक ​​कि एक साधारण रिपोर्ट परियोजना के लिए एक बड़ा योगदान हो सकता है।

हमारे उद्योग में व्याप्त गतिहीनता के कारण, हम अक्सर खुद को होने वाली समस्याओं के लिए दोषी पाते हैं। प्रलेखन में कुछ छूट गया था, या बस इतना स्मार्ट नहीं था। लेकिन पहली कहानी से सबक के बारे में मत भूलना: कोई बुरा उपयोगकर्ता नहीं हैं, केवल एक बुरा इंटरफ़ेस है। और कोई बुरा डेवलपर्स नहीं हैं, केवल खराब विकास उपकरण हैं।

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

आपने एक टाइपो बनाया, एक असंगत त्रुटि संदेश मिला और परिणामस्वरूप, आपने एक घंटे डिबगिंग खर्च किया? नए अंक या PR के साथ त्रुटि संदेश को बेहतर बनाने का यह एक शानदार अवसर है। पुस्तकालय के चारों ओर बहुत लंबे समय तक एक रास्ता खोज रहे हैं? इस बारे में सोचें कि प्रलेखन में कौन सी जानकारी आपकी मदद करेगी।

तीसरा सबक: विश्वास स्वचालन

यह कहानी 1997 में अब ख़राब हुए मीर स्पेस स्टेशन के साथ घटी।

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

1967 से, यूएसएसआर ने पूरी तरह से स्वचालित डॉकिंग सिस्टम का उपयोग किया है: पहला, इग्लू, फिर कोर्स। इन विकासों ने मीर स्टेशन को स्वचालित मॉड्यूल से बनाना संभव बना दिया, जो अपने स्वयं के कंप्यूटर, पावर सिस्टम और इंजन के साथ स्वतंत्र अंतरिक्ष यान के रूप में कार्य करते हैं।


मीर स्टेशन के मॉड्यूल।

हालांकि, सोवियत डॉकिंग सिस्टम यूक्रेन में निर्मित किए गए थे, और यूएसएसआर के पतन के बाद, मास्को और कीव कीमतों पर सहमत नहीं थे। Roscosmos, विदेशी घटकों पर अपनी निर्भरता को कम करने की कोशिश कर रहा है, एक वैकल्पिक - TORU विकसित किया है, जो दो जॉयस्टिक का उपयोग करके जहाज को दूर से नियंत्रित करने के लिए अंतरिक्ष स्टेशन पर ऑपरेटर को अनुमति देता है।

टीओआरयू ने अंतरिक्ष में सफलतापूर्वक परीक्षण किया। 1997 में, स्टेशन के लिए कार्गो के साथ प्रगति एम -34 जहाज सफलतापूर्वक दुनिया के लिए डॉक किया गया। और फिर, अप्रत्याशित रूप से, इसे बंद करने का निर्देश था, और पृथ्वी पर लौटने के बजाय, डॉकिंग सिस्टम को फिर से जांचने के लिए इसे मैन्युअल रूप से स्टेशन पर दोबारा डॉक करें।


वासिली त्सिविएव मीर स्टेशन से जहाज को नियंत्रित करता है।

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

अंतरिक्ष यात्रियों ने एक सीटी सुनी और उनके कान अवरुद्ध हो गए। स्टेशन की हवा छूट रही थी।

चालक दल को स्पेक्ट्रम से आने वाली केबलों को डिस्कनेक्ट करना था, मॉड्यूल को बंद करना और इसे बिना छोड़े छोड़ देना। और तीन साल बाद, स्टेशन सागर में बह गया।

नतीजतन, कोर्स को डॉकिंग सिस्टम से नहीं छोड़ा गया है, आज रूस में इसका निर्माण किया जा रहा है। कोर्स और TORU का उपयोग रूसी जहाजों पर किया जाता है, TORU एक बैकअप सिस्टम है।

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


1997 में प्रोग्रेस एम -34 के साथ टक्कर के बाद दुनिया को नुकसान।

इस कहानी ने मुझे लिनक्स सिस्टम को नष्ट करने वाले वीडियो कार्ड के लिए ड्राइवरों को स्थापित करने के लिए प्रसिद्ध स्क्रिप्ट की याद दिला दी। थका हुआ लाइब्रेरी डेवलपर, जो रात में काम करता था, बस एक अंतर से चूक गया:

  # GIANT BUG... causing /usr to be deleted... so sorry.... - rm -rf /usr /lib/nvidia-current/xorg/xorg + rm -rf /usr/lib/nvidia-current/xorg/xorg 

लोग गलत हैं। स्वचालन को प्राथमिकता दें। कारों को भुगतना होगा!

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

स्रोत कोड लिंटर (जैसे जावास्क्रिप्ट के लिए ESLint और CSS के लिए स्टाइललिंट ) बहुत अच्छी तरह से बग ढूंढते हैं जो आपको बहुत समय और धन खर्च कर सकते हैं। आप अपने लिंटर प्लगइन लिखने में कई घंटे बिताएंगे, लेकिन लंबे समय में यह भुगतान करेगा।

प्रलेखन में टाइपो से बचना चाहते हैं? यास्पेलर आज़माएँ । सीएसएस में कुछ क्रम में गुणों को व्यवस्थित करना चाहते हैं? अपने विकास उपकरण में स्टाइललिंट-ऑर्डर जोड़ें।

* * *

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

अंतरिक्ष अन्वेषण का इतिहास न केवल सम्मेलनों और पार्टियों के बाद मेरी कहानियों के लिए प्रेरणा है, बल्कि सही तकनीकों के स्रोत के रूप में भी काम करता है। एक जलती हुई अंतरिक्ष यान की तुलना में समस्या पर एक रिपोर्ट भेजने की आवश्यकता क्या बेहतर याद दिलाती है?