रूबी में डेटा प्रकार की समस्याओं को हल करना या डेटा को फिर से विश्वसनीय बनाना

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



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

प्रकार हैं कि आप अपने प्रोग्राम के साथ काम करने वाले डेटा का वर्णन करेंगे।

लेकिन रूबी में डेटा प्रकारों में क्या गलत है? समस्या का विस्तार से वर्णन करने के लिए, मैं कई कारणों पर प्रकाश डालना चाहूंगा।

कारण 1. रूबी की समस्याएँ

जैसा कि आप जानते हैं, रूबी तथाकथित के लिए समर्थन के साथ सख्त गतिशील टाइपिंग का उपयोग करती है । बत्तख टाइपिंग । इसका क्या मतलब है?

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

1 + '1' - 1 #=> TypeError (String can't be coerced into Integer) 

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

 x = 123 x = "123" x = [1, 2, 3] 

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

 def process(collection) return if collection.blank? collection.map { |item| do_something_with(item) } end 

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

हम यह देख सकते हैं कि एक प्रकार या किसी अन्य में गतिशील भाषाओं में किस प्रकार की जाँच जोड़ी जाती है:

• टाइपस्क्रिप्ट जावास्क्रिप्ट डेवलपर्स के लिए प्रकार की जाँच लाता है
• पायथन 3 में टाइप संकेत जोड़े गए थे
• Dialyzer Erlang / Elixir के लिए टाइप जाँच का एक अच्छा काम करता है
• रूबी 2.x में स्टीप और सोर्बेट प्रकार की जाँच जोड़ते हैं

हालांकि, रूबी में अधिक कुशलता से प्रकारों के साथ काम करने के लिए एक और उपकरण के बारे में बात करने से पहले, आइए दो और समस्याओं पर गौर करें जिनके लिए मैं एक समाधान ढूंढना चाहूंगा।

कारण 2. विभिन्न प्रोग्रामिंग भाषाओं में डेवलपर्स की सामान्य समस्या

आइए उन डेटा प्रकारों की परिभाषा याद करें जो मैंने लेख की शुरुआत में दिए थे:

प्रकार आप अपने प्रोग्राम के साथ काम करने वाले डेटा का वर्णन करते हैं।

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

यहाँ एक विशिष्ट आदिम जुनून उदाहरण है:

 price = 9.99 # vs Money = Struct.new(:amount_cents, :currency) price = Money.new(9_99, 'USD') 

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

मैं किसी अन्य मुद्दे को कवर करने के तुरंत बाद इन फायदों के बारे में बात करूंगा कि हमारी पसंदीदा रूबी रेल्स फ्रेमवर्क ने हमें सिखाया है, जिसकी बदौलत मुझे यकीन है, यहां ज्यादातर लोग रूबी के पास आए हैं।

कारण 3. वह समस्या जो रूबी ऑन रेल्स फ्रेमवर्क ने हमें दी

रूबी ऑन रेल्स, या बल्कि इसमें बने ActiveRecord ORM ढांचे ने हमें सिखाया कि ऐसी वस्तुएँ जो अमान्य स्थिति में हैं, सामान्य हैं। मेरी राय में, यह सबसे अच्छे विचार से दूर है। और मैं इसे समझाने की कोशिश करूंगा।

इस उदाहरण को लें:

 class App < ApplicationRecord validates :platform, presence: true end app = App.new app.valid? # => false 

यह समझना मुश्किल नहीं है कि app ऑब्जेक्ट में एक अमान्य स्थिति होगी: App मॉडल के सत्यापन के लिए आवश्यक है कि इस मॉडल की वस्तुओं में एक platform विशेषता है, और हमारी ऑब्जेक्ट में यह विशेषता खाली है।

अब, आइए इस वस्तु को अमान्य स्थिति में एक ऐसी सेवा में पारित करने का प्रयास करें जो App ऑब्जेक्ट को एक तर्क के रूप में बताती है और इस ऑब्जेक्ट के platform विशेषता के आधार पर कुछ क्रियाएं करती है:

 class DoSomethingWithAppPlatform # @param [App] app # # @return [void] def call(app) # do something with app.platform end end DoSomethingWithAppPlatform.new.call(app) 

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

लेकिन चलो एक गहरी समस्या के बारे में सोचते हैं। सामान्य तौर पर, हम डेटा की वैधता की जांच क्यों करते हैं? एक नियम के रूप में, यह सुनिश्चित करने के लिए कि एक अमान्य राज्य हमारे सिस्टम में लीक नहीं होता है। यदि यह सुनिश्चित करना बहुत महत्वपूर्ण है कि अमान्य राज्य की अनुमति नहीं है, तो हम अमान्य राज्य वाली वस्तुओं को बनाने की अनुमति क्यों देते हैं? विशेष रूप से जब हम ActiveRecord मॉडल के रूप में ऐसी महत्वपूर्ण वस्तुओं के साथ काम कर रहे हैं, जो अक्सर रूट बिजनेस लॉजिक को संदर्भित करता है। मेरी राय में, यह एक बहुत बुरा विचार लगता है।

इसलिए, उपरोक्त सभी को संक्षेप में, हमें रूबी / रेल में डेटा के साथ काम करने में निम्नलिखित समस्याएं हैं:

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

इन समस्याओं को कैसे हल किया जा सकता है?

मैं ऊपर वर्णित समस्याओं के समाधान में से एक पर विचार करना चाहूंगा, Appodeal में वास्तविक सुविधा कार्यान्वयन का एक उदाहरण। डेली एक्टिव यूजर्स (इसके बाद DAU) के आँकड़ों को इकट्ठा करने की प्रक्रिया में, जो कि एपोडील को मुद्रीकृत करने के लिए उपयोग किए जाने वाले आँकड़ों के लिए, हम लगभग निम्नलिखित डेटा संरचना में आए, जिन्हें हमें इकट्ठा करना है:

 DailyActiveUsersData = Struct.new( :app_id, :country_id, :user_id, :ad_type, :platform_id, :ad_id, :first_request_date, keyword_init: true ) 

इस संरचना में वही सारी समस्याएं हैं जो मैंने ऊपर लिखी हैं:

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

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

DAU इकट्ठा करने के लिए संरचना में उपयोग किए जाने वाले हमारे विषय क्षेत्र के डेटा का वर्णन करने के लिए, निम्न प्रकार की प्रणाली बनाई गई थी:

 module Types include Dry::Types.module AdTypeId = Types::Strict::Integer.enum(AD_TYPES.invert) EntityId = Types::Strict::Integer.constrained(gt: 0) PlatformId = Types::Strict::Integer.enum(PLATFORMS.invert) Uuid = Types::Strict::String.constrained(format: UUID_REGEX) Zero = Types.Constant(0) end 

अब हमें उस डेटा का विवरण प्राप्त हुआ है जो हमारे सिस्टम में उपयोग किया जाता है और जिसे हम संरचना में उपयोग कर सकते हैं। जैसा कि आप देख सकते हैं, EntityId और Uuid के प्रकारों की कुछ सीमाएँ हैं, और AdTypeId प्रकार AdTypeId और PlatformId केवल एक विशिष्ट सेट से मान हो सकते हैं। इन प्रकारों के साथ कैसे काम करें? एक उदाहरण के रूप में PlatformId पर विचार करें:

 #     enumerable- PLATFORMS = { 'android' => 1, 'fire_os' => 2, 'ios' => 3 }.freeze #       , #     Types::PlatformId[1] == Types::PlatformId['android'] #    ,    #   ,     Types::PlatformId['fire_os'] # => 2 #     ,   Types::PlatformId['windows'] # => Dry::Types::ConstraintError 

तो, प्रकारों का उपयोग करके स्वयं पता लगा लिया। अब हम उन्हें अपनी संरचना में लागू करते हैं। नतीजतन, हमें यह मिला:

 class DailyActiveUsersData < Dry::Struct attribute :app_id, Types::EntityId attribute :country_id, Types::EntityId attribute :user_id, Types::EntityId attribute :ad_type, (Types::AdTypeId ǀ Types::Zero) attribute :platform_id, Types::PlarformId attribute :ad_id, Types::Uuid attribute :first_request_date, Types::Strict::Date end 

DAU के लिए डेटा संरचना में अब हम क्या देखते हैं? dry-types और dry-struct का उपयोग करके dry-struct हमने डेटा प्रकार की जाँच की कमी और डेटा विवरण की कमी से जुड़ी समस्याओं से छुटकारा पाया। अब कोई भी व्यक्ति, इस संरचना को देख रहा है और इसमें इस्तेमाल किए गए प्रकारों के विवरण पर, यह समझ सकता है कि प्रत्येक विशेषता क्या मान ले सकती है।

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

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

परिणाम

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