जब स्टार खाली जाता है: जिम वेइरिच के साथ एक साक्षात्कार

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

मैंने लंबे समय तक जिम के बारे में सुना: आखिरकार, वह रेक यूटिलिटी के लेखक हैं, जो वास्तव में माणिकों के बीच वास्तविक मानक बन गया है। मेरे महान भाग्य के लिए, मैं GoRuCo 2012 में उनके भाषण के श्रोताओं में से था, जिसने रेक की उन्नत विशेषताओं के बारे में बात की थी। मुझे याद है कि जिम और जटिल विषयों पर बोलने वाले चपलता और सहजता से कैसे प्रभावित हुए। उस वर्ष बाद में, रूबिकॉन्फ़ सम्मेलन में, मैंने उनकी अन्य उल्लेखनीय प्रस्तुति देखी, जिसमें लैम्बो कैलकुलस के कुछ मूल सिद्धांतों की व्याख्या की गई थी। जिम ने न केवल सहजता से समझाया, यह सबसे आसान विषय नहीं है, बल्कि रास्ते में अपने श्रोताओं को भी नहीं खोना है।

मुझे लगता है कि अब आप समझ गए हैं कि मैं जिम से यह साक्षात्कार लेने के लिए क्यों खुश था, क्योंकि यह उसके बारे में थोड़ा और जानने और कुछ सीखने का एक अनूठा अवसर है। हम विकास की दुनिया में अपने रास्ते की शुरुआत के बारे में बात करने में भी कामयाब रहे, रूबी में अपने पहले कदमों के बारे में, कार्यात्मक प्रोग्रामिंग के बारे में, रूबी में थ्रेड्स के मॉडल और यहां तक ​​कि उनके परीक्षण ढांचे के बारे में भी: आरएसपीईसी-गिवेन )। तो इस साक्षात्कार को खोलें, सबसे उन्नत और करिश्माई डेवलपर्स में से एक के बारे में जानने के लिए आलसी न हों!

प्रोग्रामर का संक्षिप्त सारांश

आप डेवलपर कैसे बने? आपने किन कारणों से इस पेशे को चुना?

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

और परिचित बीसीडी का क्या मतलब है?

बीसीडी बाइनरी कोडेड डेसीमल है, एक प्रणाली जिसमें सभी संख्याओं को दशमलव अंकन (पारंपरिक बाइनरी के विपरीत) में संग्रहीत किया जाता है।

यह एक बहुत ही असामान्य मशीन वास्तुकला है, और प्रोग्रामिंग दुनिया में नौसिखिए के लिए अभी तक स्वीकार्य है। मुझे याद है कि कोड लिखना सीखने के दौरान मैं कैसे आया। मुझे लगता है कि आप अनुमान लगाते हैं कि पेशे की पसंद पर मैंने सलाहकार को क्या घोषित किया था। सच है, एक विवरणिका में एक ठेठ प्रोग्रामर का वर्णन पढ़ने के बाद, मैं विशेष रूप से उदास था।

वहां क्या लिखा गया था, उसे नष्ट न करें?

खैर, कुछ इस तरह:

"... आप गहरे अंधेरे में पूरी तरह से अकेले बैठे हैं। ... आप अपने काम के कई घंटों के लिए किसी के साथ संवाद नहीं करते हैं! "

उसके बाद, मैंने सोचा कि प्रोग्रामिंग बहुत बढ़िया है, लेकिन ऐसा काम ... नहीं, धन्यवाद!

मेरे कॉलेज के वर्षों के दौरान, हमारे सलाहकार ने मुझे सलाह दी: “आप शुरुआती पाठ्यक्रम के लिए फोरट्रान के लिए साइन अप क्यों नहीं करते हैं? आप इसे पसंद कर सकते हैं। ” जब मैं पहले पाठ के लिए आया था, तो व्याख्याता ने ब्लैकबोर्ड पर जाकर प्रक्रिया में इसे समझाते हुए कोड लिखना शुरू किया। मुझे अभी भी याद है कि पहले समारोह का नाम उन्होंने लिखा था - सदस्य। मैं एक व्याख्यान सुन रहा था और यह मुझ पर छा गया: “यह फोरट्रान की कुछ अजीब बोली है। बहुत सारे कोष्ठक! ” ओह हाँ, यह लिस्प था! जैसा कि यह निकला, मैं लिटिल लिस्पर के लेखक डैन फ्रीडमैन के पहले और एकमात्र कोर्स पर गया।

खैर, एक ब्रोशर से एक प्रोग्रामर के अशुभ विवरण के बारे में क्या?

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

खुश खोज

आप रूबी के पास कैसे आए?

यह 2000 में था, अगर मेरी स्मृति मुझे सही सेवा देती है। मैंने तब C ++ और Java में लिखा, और पर्ल में भी अच्छी तरह से (अच्छी तरह से, आप जानते हैं, रोजमर्रा की दिनचर्या को कम करने के लिए छोटी स्क्रिप्ट)। और पर्ल, दुर्भाग्य से, थोड़ी देर बाद मुझे परेशान करने लगे: यह तेज हैक के लिए एकदम सही था, लेकिन केवल इसलिए कि इस पर सुंदर सार लिखना मुश्किल है। यहां, उदाहरण के लिए, मुझे एक सूची की आवश्यकता है - कृपया इसे पर्ल में थूक दें, लेकिन जब सूचियों की एक सूची पहले से ही आवश्यक है - तब सब कुछ, भाषा अजीब तरह से व्यवहार करना शुरू कर देती है।

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



कहीं न कहीं पायथन सीखने के मेरे 3 प्रयासों के दौरान, मुझे डेव थॉमस का एक पत्र मिला, जिसमें उन्होंने लिखा: "मुझे रूबी नाम की एक छोटी सी भाषा यहां मिली और मुझे यह बहुत पसंद आई। यह आपको खुश भी कर सकती है।" द प्रैगमैटिक प्रोग्रामर पुस्तक को पढ़ें और फैसला किया कि अगर डेव खुद कुछ सुझाते हैं, तो यह निश्चित रूप से कम से कम देखने लायक है। मैंने रूबी को डाउनलोड किया, बस कुछ मिनटों के लिए उसके साथ खेला, और अचानक एहसास हुआ: “ठीक है, यह यहाँ है! यह ठीक वैसी ही भाषा है जिसकी मुझे तलाश थी! ” 3 दिनों के बाद, मैंने पर्ल में लिखना बंद कर दिया और पूरी तरह से रूबी में बदल गया।

रूबी का क्या संस्करण था?

यह रूबी 1.6 था (चूंकि यह गर्मियों में 2000 यार्ड में था)।

रूबी ने वास्तव में आपके साथ क्या किया?

उन्होंने पर्ल के समान ही सब कुछ किया, लेकिन केवल ऑब्जेक्ट-ओरिएंटेड तरीके से। मुझे याद है कि सोच रहा था: "ठीक है, मैं पर्ल में इस समस्या को लिखूंगा, लेकिन अगर मेरे पास ऑब्जेक्ट्स थे, तो मैं इस तरह से समस्या को हल करूंगा।" उसके बाद, मैं रूबी के लिए बैठ गया, और मेरा समाधान सिर्फ वस्तुओं पर बनाया गया! बेशक, एक ही समय में मैं त्वरित (और गंदे) ट्रिक्स का उपयोग कर सकता था, जैसे पर्ल ने मुझे करने की अनुमति दी थी, लेकिन थोड़ी देर बाद मैंने पाया कि रूबी के पास बस उत्कृष्ट सार थे और भाषा स्वयं बहुत सही ढंग से विकसित हुई। मैं बस खुश था कि मैं उससे मिला।

क्या रूबी कार्यात्मक है?

खैर, रूबी एक वस्तु-उन्मुख भाषा है। लेकिन क्या यह उसी समय कार्यात्मक है? और "कार्यात्मक" शब्द का क्या अर्थ है?

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

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

लेकिन एक दूसरी आवश्यकता है! यह कार्यात्मक भाषाओं को इतना दिलचस्प बनाता है। इसमें संस्थाओं की स्थिति को बदलने की अक्षमता शामिल है। रूबी इस आवश्यकता को पूरा नहीं करती है, क्योंकि यह लगातार वस्तुओं की स्थिति बदलती है!

इसके मल्टीथ्रेडिंग कार्यान्वयन के लिए कार्यात्मक प्रोग्रामिंग दिलचस्प है। बहु-थ्रेडेड प्रोग्रामिंग में महत्वपूर्ण समस्याओं में से एक दौड़ की स्थिति है, उदाहरण के लिए, आपके पास एक ही डेटा के साथ काम करने वाले 2 धागे हैं। इस दौड़ के साथ यह ज्ञात नहीं है कि कौन जीतेगा। उदाहरण के लिए, काउंटर में वृद्धि। 2 धागे हैं, जिनमें से पहला वर्तमान मूल्य पढ़ता है, इसे मेमोरी रजिस्टर में बढ़ाता है और फिर इसे वापस रखता है। इस समय, दूसरी धारा पढ़ती है, मूल्य बढ़ाती है और इसे लिखती है। यदि (और केवल अगर), वे एक के बाद एक सख्त क्रम में वैकल्पिक रूप से शुरू करेंगे और हम 10 नंबर से शुरू करेंगे, तो 11, 12 और इतने पर होंगे। आपको बहुत सावधान रहने की जरूरत है, जब थ्रेड्स शेयर संसाधनों को बदला जा सकता है।

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

मुझे डर है कि रूबी इससे पीड़ित है, क्योंकि प्रवाह के लिए उसका मॉडल 1960-1970 से आता है।

रूबी थ्रेडिंग मॉडल

हाँ, विशेष रूप से एमआरआई रूबी। मैं व्यक्तिगत रूप से मानता हूं कि दुभाषिया स्वयं धागा सुरक्षित नहीं है। क्या सच में ऐसा है?

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



हालांकि, क्या JRuby और Rubinius धागा सुरक्षित हैं?

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

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

10 प्रकाशन जो प्रत्येक डेवलपर को पढ़ना चाहिए

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

ये अस्सी साल पुरानी बातें हैं!

क्या आप अभी भी अपनी आस्तीन में ऐसी चीजें हैं?

2009 में, माइकल फेयर्स ने "10 पेपर्स एव प्रोगामर रीड रीड एट लिस्ट ट्वाइस" लेख लिखा ( दुर्भाग्य से, मूल लेख अब उपलब्ध नहीं है )।

पहली पुस्तक डेविड परन द्वारा लिखी गई है और "मॉड्यूल में डिकम्पोजिंग सिस्टम में उपयोग किए जाने वाले मानदंडों पर" का हकदार है। उन्होंने संदर्भ में एक साधारण कार्यक्रम, कीवर्ड लिखा था।



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

क्या यह ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (OOP) के विचारों में से एक नहीं है?

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

एक और अच्छा लेख जॉन बैकस द्वारा लिखित वॉन न्यूमैन शैली से मुक्त किया जा सकता है । यह पहले प्रकाशनों में से एक है जिसे उन्होंने "एमएल" कहा है, जो कि एक कार्यात्मक प्रोग्रामिंग भाषा है। ML, हास्केल और OCalm जैसी भाषाओं का आधार बन गया है।

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

प्रदर्शन

आपके पास एक प्राकृतिक प्रतिभा है: आप बहुत जटिल विषयों की व्याख्या कर सकते हैं। आप इसे कैसे करते हैं?

तुम्हें पता है, मैंने प्रदर्शनों के बारे में पुस्तकों का एक समूह पढ़ा: कैसे ठीक से तैयार करना है, कैसे आचरण करना है, वास्तव में, एक प्रदर्शन और इतने पर। सभी पुस्तकों में, सीमांत नोट और अन्य समान चीजों को लेने की सिफारिश की जाती है - लेकिन यह दृष्टिकोण मेरे साथ काम नहीं करता है!

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

उसके बाद, मैं कागज पर एक दिलचस्प कहानी लिखने की कोशिश करता हूं, मेरे परिणामस्वरूप ग्राफ के साथ चलना। जरूरी नहीं कि जिस क्रम में विचारों को व्यवस्थित किया जाए, निश्चित रूप से।

यही है, क्या यह तकनीकी लेखक जैसा कुछ है?

हाँ, मुझे वह विवरण पसंद है!

एक दिलचस्प कहानी में लैम्ब्डा कैलकुलस जैसे कठिन विषय को बदलना एक कला है। मुझे लगता है कि 80 साल पहले लिखे गए इस विषय पर मूल वैज्ञानिक कार्यों को पढ़ने की कोशिश करते समय बहुतों ने अपनी आँखें खो दी होंगी।

मेरा मानना ​​है कि एक सफल प्रदर्शन की कुंजी जलती हुई आँखें हैं। यदि आप जो बता रहे हैं, वह सबसे पहले अपने आप में दिलचस्प है, तो यह बाकी दर्शकों के लिए दिलचस्प होगा। क्या आप जानते होंगे कि जब मैं पढ़ रहा था तो मैं एक बहुत नीरस आवाज के साथ प्रोफेसरों से मिला था! यह शांत हॉरर है। इस अविस्मरणीय अनुभव के बाद, मैंने फैसला किया कि अगर मैं कभी भी प्रदर्शन करूंगा , तो मैं अपने व्याख्याताओं के तरीके से कभी नहीं करूंगा । प्रदर्शन के लिए ये सभी तैयारी - यह, ज़ाहिर है, अच्छा है और यह मदद करता है, लेकिन बोलते समय आपकी आंखों में लौ अधिक महत्वपूर्ण है।

Rspec प्रदत्त

क्या आप अब और प्रदर्शन करने की योजना बना रहे हैं?

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

क्या इस ढांचे में बीडीडी दर्शन के साथ कुछ भी सामान्य है? ककड़ी के बारे में क्या? या तथ्य यह है कि आप एक ही 3 खोजशब्दों का उपयोग सिर्फ एक संयोग है?

यह सिर्फ एक संयोग है, मेरा ढांचा ककड़ी से संबंधित नहीं है, हालांकि मुझे यह पसंद है कि कब / कब / इसके बाद इसका उपयोग किया जाए।

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

लगभग 2-3 साल पहले, मैंने इस समस्या को प्रतिबिंबित किया, कागज पर अपने विचारों को कुरेदना। उस समय, मैं नैशविले में रूबी होडाउन सम्मेलन में था। मैंने फीडबैक और राय एकत्र करने के लिए कागज के इस स्क्रैप को पड़ोस में डेवलपर्स को सौंप दिया। और फिर जो ओ ब्रायन मेरी ओर मुखातिब हुए और कहा: "क्या आप एक और परीक्षण रूपरेखा नहीं लिखने जा रहे हैं?"

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

अनुवादक से: कृपया निजी संदेशों का उपयोग करते हुए बग्स की रिपोर्ट करें, उन्हें जल्दी ठीक कर लिया जाएगा।

संदर्भ:

• जिम की जीवनी: en.wikipedia.org/wiki/Jim_Weirich
• GoRuCo 2012 में जिम का भाषण (रेक यूटिलिटी के लिए समर्पित): www.confreaks.com/videos/988-goruco2012-power-rake
• रूबी कॉन्फ्रेंस 2012 में जिम स्पीच (Y Not - एडवेंचर्स इन फंक्शनल प्रोग्रामिंग): www.confreaks.com/videos/1287-rubyconf2012-y-not-adventures-in-functional-programming
• Rspec- दिया गया पुस्तकालय: github.com/jimweirich/rspec-given
• अंतिम वचन: github.com/jimweirich/wyriki/commit/d28fac7f18aeacb00d8ad3460a0a5a901617c2d4