रैंडम 'चिंताओं' फ़ोल्डर और '.keep' फाइलें

Question

मैं रेल सीख रहा हूं।

कहीं रेखा के साथ, मैंने देखा कि प्रतीत होता है कि यादृच्छिक फ़ोल्डर और फाइलें मेरे रेल एप्लिकेशन की निर्देशिका में दिखाई दे रही हैं। कुछ फ़ोल्डरों में एक concernsफ़ोल्डर होता है जिसके .keepअंदर एक फ़ाइल होती है। .keepफ़ाइल रिक्त प्रतीत होता है। अन्य फ़ोल्डरों में कोई concernsफ़ोल्डर नहीं है, लेकिन एक खाली .keepफ़ाइल मौजूद है।

क्या किसी को पता है कि इन फ़ाइलों / फ़ोल्डरों के साथ सौदा क्या है?

Answer 1

.keepफाइलें 0 बाइट फाइलें हैं जो सभी प्रकार की प्रक्रियाओं से खाली फ़ोल्डरों को अनदेखा करने से रोकने के लिए हैं। किसी बारे में चिन्ता की जरूरत नहीं।

Comments

बहुत धन्यवाद! तो क्या मैं उन्हें छोड़ दूं? मैं उन्हें हटाने जा रहा था यदि वे आवश्यक नहीं हैं

— एलेक्स वाल्लेजो

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

— जोश

क्या मुझे उन्हें अपने अंदर रखना चाहिए .gitignore? मैं नहीं बल्कि खाली फाइल करना चाहते हैं।

— tbodt

@tbodt मैं उन्हें प्रतिबद्ध करूंगा। यकीन नहीं होता कि अगर कोई और आपके कोडबेस को क्लोन कर ले तो क्या होगा।

— डिकीबॉय

Answer 2

जब आप खाली निर्देशिकाओं को गिट से कमिट करना चाहते हैं तो .की फाइलें विशेष रूप से सहायक होती हैं।

मजेदार तथ्य, नाम .keepया .gitkeepअर्थहीन। आप .fooएक ही प्रभाव के लिए फ़ाइल को कॉल कर सकते हैं , यह केवल एक पठनीय सम्मेलन है।

.keepफ़ाइलों को भी वहाँ सहायता Portage करने के लिए एक VCS से दूसरे में, महत्वपूर्ण निर्देशिकाओं का विलोपन को रोकने जब आप अलग कुछ है कि उन निर्देशिकाओं खाली होने का कारण बन रहे हैं।

उदाहरण के लिए, एक स्क्रिप्ट पर विचार करें जो cd dirएक निर्देशिका में प्रयास करती है जो गिट द्वारा अनुपलब्ध है।

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

Answer 3

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

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

 class Services::GenerateCsv
     def self.get_users org
         #add logic the fetch users for the org and generate the CSV and return the CSV data
     end
 end

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

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