इसे करने में कितना समय लगेगा? इस परिवर्तन को करने में कितना कठिन होगा? अगर आप गुस्सा और निराश होना शुरू कर रहे हैं, तो आप शायद एक सॉफ्टवेयर डेवलपर हैं। अनुमान दर्दनाक है, खासकर जब अनुमान लगाने के लिए कहने वाला व्यक्ति (चलिए उन्हें बॉब कहते हैं) के पास केवल एक मोटा विचार है कि वे क्या मांग रहे हैं।

मैं इसका उत्तर एक स्क्रीनशॉट के साथ दूंगा: {% img img-responsive /images/posts/ruby-2-1-improvement.png 645 259 मैं इसे एक बड़ा हां कहूंगा %} हमने लगभग एक हफ्ते पहले प्रोडक्शन में रूबी 1.9 से 2.1 में अपग्रेड किया, और ये वही है जो हमने देखा। नीचे ग्रे सेक्शन हमारा गार्बेज कलेक्शन समय है जो लगभग शून

आपने एक नया प्रोजेक्ट शुरू किया है और आपके कोड के लिए किसी थर्ड-पार्टी सर्विस पर निर्भर होने का समय आ गया है। ये इलास्टिकसर्च, रेसक्यू, बिलिंग प्रोवाइडर, या सिर्फ एक मनमाना HTTP API जैसा कुछ हो सकता है। आप एक अच्छे डेवलपर हैं, इसलिए आप इस कोड को अच्छी तरह से टेस्ट करना चाहते हैं। लेकिन आप उस कोड को

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

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

मैं कुछ लोगों से सुन रहा हूँ जो बड़े रेल्स व्यूज़ को छोटे पार्शियल्स में तोड़ने के बारे में चिंतित हैं: एक पार्शियल को रेंडर करने में वास्तव में कितना समय लगता है? क्या पार्शियल्स को कॉल करने के प्रदर्शन प्रभाव, कोड पठनीयता में लाभ से अधिक होंगे? मैंने कुछ संख्याएँ चलाईं ताकि एक उदाहरण दे सकूं कि क

रेल्स कंट्रोलर्स में खोज, सॉर्टिंग और फ़िल्टरिंग एक दर्द हो सकता है। ElasticSearch और Solr बेहतरीन, उच्च-शक्ति वाले समाधान हैं, लेकिन एक छोटे ऐप के लिए वास्तव में बड़ी निर्भरताएं हैं। सौभाग्य से, रेल्स में स्कोप्स शामिल हैं, जो सरल खोज, फ़िल्टरिंग और सॉर्टिंग के लिए आपको जो चाहिए उसका बहुत कुछ प्रद

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

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

आपने अपने अगले प्रोजेक्ट पर rails new टाइप किया है। अब क्या? कहां से शुरू करें? क्या आप सब कुछ एक ही ऐप में लिखते हैं, या सर्विस ओरिएंटेड आर्किटेक्चर के साथ जाते हैं? क्या RSpec सीखने का ये अच्छा समय है? क्या आपको अपने सभी डेटा मॉडल्स बनाना शुरू करना चाहिए, या कुछ एक्शन्स को एंड-टू-एंड काम करना चाहि

पिछले हफ्ते, मैंने तीन कन्वेंशन्स के बारे में बात की थी जो टालमटोल को हराने और आपके नए रेल्स प्रोजेक्ट को शुरू करने में मदद कर सकते हैं। अब तक आपको सामने आने वाले काम से कम अभिभूत महसूस होना चाहिए। लेकिन आपके पास अभी भी एक कठिन विकल्प है। आप पहले कौन सा कोड लिखते हैं? ऑथेंटिकेशन? वो हिस्सा जो ट्विलि

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

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

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

आपके रेल्स करियर में किसी बिंदु पर, आप एक ऐसे कंट्रोलर में फंसेंगे जो आपको हमेशा के लिए प्रोग्रामिंग छोड़ने पर मजबूर कर देगा। इसमें पूरी फीचर के लिए कोड की हर लाइन हो सकती है। इसमें 15 before_filters हो सकते हैं जो सभी इंस्टेंस वेरिएबल के माध्यम से संवाद करते हैं और जिन्हें एक विशिष्ट क्रम में कॉल क

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

मैंने TDD के बारे में बहुत कुछ लिखा है। इसलिए, यह कोई आश्चर्य की बात नहीं है कि जब मैंने अपना पिछला लेख लगभग सटीक मिनट पर प्रकाशित किया जब डेविड हाइनमेयर हेंसन ने अपने रेल्सकॉन्फ कीनोट के दौरान TDD का उल्लेख किया, तो मुझे कुछ सवाल मिले: क्या आप DHH के TDD पर विचारों से सहमत हैं? क्या आप अभी भी TDD क

वह if स्टेटमेंट्स का विशाल गड़बड़ आपको घूरता रहता है। आपको लगता है कि आप कर सकते हैं इसे सरल बनाने में सक्षम, सिवाय उस बिजनेस लॉजिक के जो रास्ते में आती रहती है। उदाहरण के लिए, मान लीजिए आपके पास एक सेल्स प्लेटफॉर्म है जहां आप Quote बनाते हैं, जिनमें कई LineItem होते हैं। सिवाय, आपके पास एक कोट में

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

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