वैज्ञानिक के साथ क्रिटिकल रूबी ऑन रेल्स कोड को दोबारा तैयार करना:एक सिद्ध दृष्टिकोण
<पी> किसी भी सॉफ्टवेयर इंजीनियर से उत्पादन कोड के प्रमुख भागों की समीक्षा करने के लिए कहें, और अनिवार्य रूप से, वे तीन चीजें बताएंगे जिन्हें दोबारा तैयार करने की आवश्यकता है। तो इतना खराब, भंगुर, या गलत समझा गया कोड उत्पादन में क्यों चलता रहता है? <पी> उत्तर सरल है:इंजीनियर इसे छूने से डरते हैं। रिफैक्टरिंग कार्यों की पहचान की जाती है और उन्हें बैकलॉग में जोड़ा जाता है, लेकिन वे शायद ही कभी इसे मौजूदा स्प्रिंट में शामिल कर पाते हैं। <पी> इसके कई कारण हैं. कोड संभवतः एक इंजीनियर द्वारा लिखा गया होगा जिसने वर्षों पहले टीम छोड़ दी थी, और कोई भी इसे पूरी तरह से नहीं समझता है। अन्य मामलों में, क्षमता व्यवसाय के लिए महत्वपूर्ण है। कोई भी संभावित आउटेज या राजस्व हानि के लिए जिम्मेदार नहीं होना चाहता। <पी> इस पोस्ट में, हम जांच करेंगे कि आप वैज्ञानिक का उपयोग माइग्रेट करने, रिफैक्टर करने और महत्वपूर्ण रूबी उत्पादन कोड को विश्वास के साथ बदलने के लिए कैसे कर सकते हैं। <पी> लेकिन सबसे पहले, आप पूछ सकते हैं - क्या हम कोड समस्याओं का पता लगाने के लिए परीक्षणों का उपयोग नहीं कर सकते? रेल परीक्षण इसी के लिए है, है ना?
<पी> हाँ, और नहीं. तैनाती से पहले कोड परिवर्तनों में पूर्ण विश्वास हासिल करना अक्सर मुश्किल होता है। यूनिट और सिस्टम परीक्षण पास हो जाते हैं। जाना अच्छा है, है ना? <पी> हकीकत तो यह है कि वास्तविक दुनिया यानी उत्पादन का कोई विकल्प नहीं है। यदि डेटा गुणवत्ता ख़राब है या परीक्षण अनुपलब्ध हैं तो क्या होगा? आप कैसे जान सकते हैं कि नया सॉफ़्टवेयर उत्पादन थ्रूपुट को संभालने के लिए पर्याप्त रूप से अच्छा प्रदर्शन करेगा? <पी> सार्वजनिक सेवाओं वाली टीमों को कभी-कभी लगता है कि उन्हें "बगवर्ड संगतता" समस्याओं से निपटने की आवश्यकता है। जब कोई बग कुछ समय के लिए उत्पादन में मौजूद होता है, तो ग्राहक इस तरह से कोड कर सकते हैं जो लगातार गलत व्यवहार पर निर्भर करता है। ग्राहक अक्सर अप्रत्याशित तरीकों से सॉफ़्टवेयर का उपयोग करते हैं। वैज्ञानिक के साथ रूबी और रेल्स में उत्पादन परिवर्तन का निरीक्षण करें
<पी> यदि परिवर्तन में विश्वास हासिल करने के लिए उत्पादन सबसे अच्छी जगह है, तो यह देखने पर विचार करें कि कोड वहां कैसे व्यवहार करता है। यह पहली बार में डरावना लग सकता है, क्योंकि "उत्पादन में परीक्षण" का विचार क्लासिक सॉफ्टवेयर इंजीनियरिंग प्रथाओं का खंडन करता है। <पी> हालाँकि, अच्छी खबर यह है कि साइंटिस्ट रत्न का उपयोग करके रूबी और रेल्स में ऐसा करना आसान और सुरक्षित है। वैज्ञानिक का नाम किसी दी गई परिकल्पना को सत्यापित करने के लिए प्रयोग करने की वैज्ञानिक पद्धति पर आधारित होता है। इस मामले में, हमारी परिकल्पना यह है कि नया कोड काम करता है। <पी> हम इस दृष्टिकोण को सुरक्षित रूप से अपना सकते हैं इसका कारण यह तथ्य है कि प्रयोग अभी भी मौजूदा कोड के परिणाम का उपयोग करते हैं। नए कोड का मूल्यांकन केवल अवलोकन और तुलना उद्देश्यों, सटीकता और प्रदर्शन दोनों के लिए किया जाता है। हम वास्तविक दुनिया के डेटा और मापदंडों का उपयोग करके प्रदर्शन का मूल्यांकन करके पहले चर्चा की गई परीक्षण कवरेज चिंताओं को कम करते हैं। प्रयोग आम तौर पर उत्पादन पर प्रभाव को कम करने के लिए अनुरोधों की चुनी गई नमूना दर का मूल्यांकन करते हैं। हालाँकि, यदि आप चाहें तो आप प्रत्येक अनुरोध का मूल्यांकन कर सकते हैं। <पी> आइए अब एक नज़र डालें कि वैज्ञानिक किसी शाखा में अमूर्त तरीके से कैसे काम करते हैं। रूबी के वैज्ञानिक में अमूर्त पैटर्न द्वारा शाखा
<पी> वैज्ञानिक का दृष्टिकोण ब्रांच बाय एब्स्ट्रैक्शन पैटर्न से शुरू होता है जिसे मार्टिन फाउलर ने "क्रमिक तरीके से एक सॉफ्टवेयर सिस्टम में बड़े पैमाने पर बदलाव" के रूप में वर्णित किया है। <पी> हम अद्यतन किए जा रहे कोड को अलग करने के लिए एक अमूर्त परत पेश करते हैं। यह परत तय करती है कि किस कार्यान्वयन का उपयोग किया जाए ताकि प्रयोग बाकी सिस्टम के लिए पारदर्शी हो। तकनीक एक फ़ीचर फ़्लैग का उपयोग करने से संबंधित है जो कोड पथ निर्धारित करता है। <पी> वैज्ञानिक रत्न, जो जीथब से उत्पन्न हुआ, एक प्रयोग का उपयोग करके इस पैटर्न को लागू करता है। मौजूदा कोड को नियंत्रण कहा जाता है, और नया कार्यान्वयन उम्मीदवार है। दोनों कोड पथ यादृच्छिक क्रम में चलाए जाते हैं, लेकिन क्लाइंट को केवल नियंत्रण परिणाम लौटाया जाता है। रूबी सेवा को दोबारा तैयार करने के लिए वैज्ञानिक का उपयोग करना
<पी> एक रूबी सेवा पर विचार करें जो किसी दिए गए नंबर के लिए सबसे बड़ा अभाज्य कारक लौटाती है। मान लें कि हमने सेवा में तेजी लाने के लिए उम्मीदवारों के आवश्यक समूह की छंटनी करने के लिए अनुकूलन की पहचान कर ली है। <पी> हालाँकि, सेवा मालिक यह सुनिश्चित करना चाहते हैं कि कोई बग पेश न किया जाए। वे प्रदर्शन में कोई सुधार भी देखना चाहते हैं. इस विधि को कॉल करने के लिए ग्राहकों को संशोधित करते हुए, निम्नलिखित कोड का परिचय दें: <पी> इस बिंदु पर, केवल use (नियंत्रण) अभिव्यक्ति का आह्वान किया जाता है। प्रयोग को सार्थक बनाने के लिए, एक कस्टम Experiment परिभाषित करें class इसे सक्षम करने के लिए (नीचे 100% समय) और परिणाम प्रकाशित करें (इस मामले में, बस लॉगिंग)। वैज्ञानिक शानदार डेटा उत्पन्न करता है लेकिन वह डिफ़ॉल्ट रूप से इसके साथ कुछ नहीं करता है। वह हिस्सा आप पर छोड़ दिया गया है। <पी> प्रयोग के परिणाम लॉग किए जाएंगे, और हम फीडबैक के आधार पर समय के साथ सुधार कर सकते हैं। एक बार जब नया कोड आवश्यकताओं को पूरा कर लेता है और आत्मविश्वास बढ़ जाता है, तो नए कार्यान्वयन के लिए विज्ञान कोड को एक प्रतिनिधिमंडल के साथ बदलकर नए कार्यान्वयन में कटओवर पूरा करें। लैबटेक रूबी ऑन रेल्स में वैज्ञानिक प्रयोगों को सरल बनाता है
<पी> साइंटिस्ट को आसानी से कॉन्फ़िगर करने और परिणामों को संभालने के लिए आप अपने रेल एप्लिकेशन में लैबटेक रत्न का उपयोग कर सकते हैं। <पी> AppSignal का उपयोग करने वाले एप्लिकेशन Appsignal.instrument का उपयोग कर सकते हैं कस्टम इंस्ट्रुमेंटेशन हेल्पर यह ट्रैक करने के लिए कि वैज्ञानिक घटनाओं को पूरा होने में कितना समय लगता है। इवेंट को प्रदर्शन टाइमलाइन में प्रदर्शित होते देखने के लिए इसे विभिन्न प्रयोग कोड ब्लॉकों के चारों ओर लपेटें। <पी> अब, लैबटेक पर वापस जा रहे हैं - नीचे दिया गया वेब पेज केवल एक संख्या को कारक के रूप में स्वीकार करता है। <पी> 
<पी> आरंभ करना आसान है बशर्ते आपके पास कंसोल तक पहुंच हो। सबसे पहले, LabTech रत्न को अपने Gemfile में जोड़ें और bundle install चलाएँ . <पी> तालिकाएँ परिणाम और प्रयोग कॉन्फ़िगरेशन संग्रहीत करती हैं, इसलिए डेटाबेस माइग्रेशन चलाएँ। <पी> एब्स्ट्रैक्शन परत वही है, सिवाय इसके कि लैबटेक मॉड्यूल का उपयोग किया जाता है। पूरा कोड GitHub पर उपलब्ध है। <पी> इस बिंदु पर, प्रयोग अक्षम है, इसलिए इसे सभी मामलों में या कुछ प्रतिशत समय के लिए सक्षम करने के लिए कंसोल का उपयोग करें। <पी> अब हम परीक्षण चला सकते हैं और प्रयोग का मूल्यांकन किया जाएगा। परिणामों के पाठ्य दृश्य के लिए, रेल्स कंसोल से निम्न में से किसी एक कमांड का उपयोग करें। <पी> कुछ सफल रन और एक निर्मित त्रुटि के बाद, यहां एक उदाहरण दिया गया है कि परिणाम सारांश कैसा दिखता है। इसमें सफलताओं और असफलताओं का अवलोकन है, साथ ही प्रदर्शन अंतर दिखाने वाला ASCII चार्ट भी है। <पी> ब्लेज़र रत्न परिणामों का आसानी से विश्लेषण करने का एक अच्छा तरीका प्रदान करता है। इसे स्थापित करना आसान है और यह SQL क्वेरी को तालिकाओं के विरुद्ध चलाने की अनुमति देता है। यहां क्वेरी से पता चलता है कि उम्मीदवार का कार्यान्वयन मूल की तुलना में काफी तेज है। <पी> 
<पी> उदाहरण प्राइम फैक्टरिंग सेवा में, बेहतर कार्यान्वयन में गति एक अनुमान से आती है जो विचार करने के लिए कुछ संभावित कारकों को समाप्त कर देती है। जैसे ही हम उच्च संख्याओं पर विचार करते हैं और एक अभाज्य कारक ढूंढते हैं, हम उस कारक से विभाजित अपने लक्ष्य संख्या तक पहुंचने के बाद खोज करना बंद कर सकते हैं। नया कोड पथ इसे पूरा करने के लिए केवल एक कथन जोड़ता है। <पी> हम लैबटेक तालिकाओं के विरुद्ध ब्लेज़र क्वेरी का उपयोग करके निष्पादन समय में कमी भी देख सकते हैं। <पी> 
वैज्ञानिकों के उपयोग के मामले और सीमाएं
<पी> वैज्ञानिकों के लिए इष्टतम उपयोग के मामलों में खोज, गणना और कोड शामिल हैं जिनका कोई दुष्प्रभाव नहीं है। कोड जिसमें लेनदेन संबंधी अपडेट या ईमेल जैसे बाहरी एकीकरण शामिल हैं, मॉडल में स्पष्ट रूप से फिट नहीं होता है क्योंकि क्षमता दो बार चलती है (पुराने और नए दोनों कार्यान्वयन)। <पी> यह कोई मामूली सीमा नहीं है, क्योंकि यह कई उपयोग के मामलों को ख़त्म कर देता है। हालाँकि, यदि प्रयोग आपकी सफलता के लिए महत्वपूर्ण है तो कुछ समाधान मौजूद हैं। विचार करें कि क्या दुष्प्रभाव प्रासंगिक हैं या क्या दोहराव कोई समस्या है। उदाहरण के लिए, कुछ मामलों में इससे कोई फर्क नहीं पड़ता कि मूल्यांकन के दौरान दो ईमेल भेजे गए हैं या नहीं। दूसरा विकल्प यह है कि नए कोड से परिणाम निर्धारित किया जाए लेकिन उसे कायम न रखा जाए। इससे किसी भी सार्थक प्रदर्शन तुलना को रोका जा सकेगा। हालाँकि, यह आपको सटीकता सत्यापित करने की अनुमति देगा। <पी> अन्य सीमाएँ वैज्ञानिक के रिटर्न मूल्यों पर ध्यान केंद्रित करने से उत्पन्न होती हैं। कुछ मामलों में, वैध परिणाम समय के साथ अंतर प्रदर्शित कर सकते हैं, चाहे वे केवल प्रतिक्रिया में टाइमस्टैम्प शामिल करें या कुछ कारक भिन्न हों। कई मामलों में, हम बुनियादी स्ट्रिंग तुलनाओं से परे सटीकता को सत्यापित करने के लिए प्रयोग में कस्टम तुलना तर्क लिख सकते हैं। <पी> अंत में, लैबटेक की एक सीमा यह है कि लेखन के समय तक इसे रेल्स 7 में पोर्ट नहीं किया गया है। रेल में प्रभावी वैज्ञानिक प्रयोगों के लिए सर्वोत्तम अभ्यास
<पी> अपने प्रयोगों को कार्यान्वित करते समय इन वस्तुओं पर विचार करें: - रेल परियोजनाओं में, साइंटिस्ट को या तो इनिशियलाइज़र या रेल्स लैबटेक रत्न की तरह एक रैपर में कॉन्फ़िगर किया जा सकता है। अधिकांश रेल अनुप्रयोगों में पहले से ही एक डेटाबेस होता है, इसलिए लैबटेक परिणामों को संग्रहीत करने के लिए ActiveRecord का लाभ उठाता है।
- विकास और परीक्षण को धीमा करने से बचने के लिए, अपने प्रयोग को केवल स्टेजिंग और उत्पादन परिवेश में सक्षम करें।
- उत्पादन पर किसी भी संभावित प्रभाव को कम करने के लिए, केवल अनुरोधों के प्रतिशत पर ही प्रयोग चलाएं। जब आप प्रयोग को सक्षम करते हैं तो लैबटेक एक वैकल्पिक पैरामीटर के रूप में इसका समर्थन करता है (यह प्रारंभ में डिफ़ॉल्ट रूप से अक्षम होता है)। शुद्ध वैज्ञानिक का उपयोग करते हुए, इस तर्क को प्रयोग के
enabled? में कोड करना आसान है विधि.
- कुछ तर्क संसाधन-गहन हैं, इसलिए कम नमूना दर शुरू करने के लिए एक अच्छी जगह हो सकती है। जैसे-जैसे आप परिणामों के प्रति आश्वस्त होते जाएं, मूल्यांकन किए जा रहे अनुरोधों का प्रतिशत बढ़ाएं।
- आप अपने परिणामों से अधिकतम लाभ प्राप्त करने के लिए संदर्भ विशेषताएँ जोड़ सकते हैं। प्रयोग संदर्भ को डेटा के प्रतीक-कुंजी वाले हैश पर सेट किया जा सकता है जिसे बाद में प्रकाशित परिणामों में उपलब्ध कराया जाता है, उदाहरण के लिए:
रैप-अप:वैज्ञानिक के साथ अपने रूबी ऐप का निरीक्षण और निगरानी करें
<पी> इस पोस्ट में, हमने पता लगाया कि उत्पादन में रूबी कोड को बदलने, स्थानांतरित करने और रिफैक्टर करने के लिए वैज्ञानिक रत्न का उपयोग कैसे करें। <पी> हमने अमूर्त पैटर्न द्वारा शाखा में वैज्ञानिक की उत्पत्ति की जांच की, फिर रिफैक्टरिंग में गोता लगाया। इसके बाद, हमने देखा कि कैसे लैबटेक परिणाम और आपके वैज्ञानिक कॉन्फ़िगरेशन को इकट्ठा करने में मदद कर सकता है। <पी> अंत में कुछ सर्वोत्तम प्रथाओं को रेखांकित करने से पहले हमने वैज्ञानिक की कुछ सीमाओं को छुआ। <पी> आपको अपने सिस्टम में क्या हो रहा है उसका अवलोकन और निगरानी करनी चाहिए। अधिक आत्मविश्वास के साथ अपने रूबी कोड में महत्वपूर्ण परिवर्तन करने के लिए वैज्ञानिक को अपनी विकास प्रक्रिया में एकीकृत करें। <पी> हैप्पी कोडिंग! <पी> पी.एस. यदि आप प्रेस से हटते ही रूबी मैजिक पोस्ट पढ़ना चाहते हैं, तो हमारे रूबी मैजिक न्यूज़लेटर की सदस्यता लें और एक भी पोस्ट न चूकें! 
डैरेन ब्रोमर
<पी> डैरेन को लिखित शब्दों के माध्यम से प्रेरणा देना और जटिल चीजों को समझना आसान बनाना पसंद है। उनकी रुचियों में विज्ञान और भौतिकी और उन दोनों को समझने के लिए पर्याप्त गणित शामिल है। वह उच्च गुणवत्ता वाली सामग्री और प्रौद्योगिकी समाधान बनाता है, और कभी-कभी इसके बारे में ट्वीट करता है। <पी> डैरेन ब्रोमर द्वारा सभी लेख
