क्या यह मौजूद है: फ़ाइल-सिस्टम संरचना का दस्तावेजीकरण करने का एक मानकीकृत तरीका


11

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

फिलहाल, मैंने इसे उस डायरैक् ट फ़ाइल का उपयोग करके प्रलेखित किया है, जो readmeमैं चाहता हूं कि प्रत्येक निर्देशिका में एक फ़ाइल का उपयोग किया जाए । यदि कोई अनिश्चित है कि किसी भी निर्देशिका में होने का क्या मतलब है, तो उन्होंने उस फ़ाइल को पढ़ा।

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

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

मुझे लगता है कि इस तरह के मानक को लागू करने का प्रयास प्रयोज्य लाभ में कई बार वापस आ जाएगा। हम कहते हैं, Nautilus, Konqueror, आदि के लिए प्लगइन्स .. इसका उपयोग webservers द्वारा दी गई मानक फ़ाइल सूचियों में निर्देशिका जानकारी प्रदर्शित करने के लिए किया जा सकता है। और इसी तरह।

तो, सवाल: क्या ऐसा होता है? यदि नहीं, तो क्यों नहीं? क्या लोगों को लगता है कि यह एक सार्थक विचार है?


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

इसलिए, आधुनिक फाइल सिस्टम में मानक परिवर्धन के रूप में, इन तीन विशेषताओं को डिफ़ॉल्ट रूप से आना चाहिए: 1) फ़ाइल विवरण, 2) एक फ़ोल्डर के अंदर कस्टम फ़ाइल ऑर्डरिंग, और 3) फ़ाइल टैगिंग / लेबलिंग। इन 3 "बुनियादी" सुविधाओं के लाभ के लिए किसी को सीएमएस का उपयोग करने की आवश्यकता नहीं होनी चाहिए।
सोरिन पोस्टेलनिकु

जवाबों:


5

जहां तक ​​मुझे पता है कि कोई मानक नहीं है। यहाँ मेरे अनुभव से कुछ विचार हैं।

इसे सेट करें, इसे कभी न बदलें

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

वर्णनात्मक और सुसंगत निर्देशिका नामों का उपयोग करें

किसी के पास .filingफाइल या कुछ और पढ़ने का समय नहीं है। यदि आपकी निर्देशिका के नाम स्वयं की व्याख्या नहीं कर रहे हैं तो आप शायद वैसे भी खो गए हैं।

अपनी निर्देशिका संरचना के लिए एक दस्तावेज लिखें

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


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

क्या ऐसी किसी वस्तु का अस्तित्व है?

नहीं, मुझे ऐसा नहीं लगता।

यदि नहीं, तो क्यों नहीं?

मेरी राय में: कुछ उपयोगकर्ताओं के साथ एक छोटी सी स्थैतिक पदानुक्रम के लिए यह ओवरकिल है। कई उपयोगकर्ताओं के साथ एक बड़े बदलते पदानुक्रम के लिए यह काम नहीं करेगा क्योंकि श्रेणियों (= निर्देशिका, फ़ोल्डर) का विचार पैमाने पर नहीं है।

क्या लोगों को लगता है कि यह एक सार्थक विचार है?

हम्म, यह एक दिलचस्प विचार है। यह देखने के लिए कि क्या लोग इसका उपयोग करेंगे, किसी को इसे लागू करना होगा। एक .filingफ़ाइल के बजाय आप उस जानकारी को एक वैकल्पिक डेटा स्ट्रीम में संग्रहीत कर सकते हैं (हाँ, फ़ोल्डर्स में एडीएस भी हो सकते हैं)। आप लिनक्स और OSX पर विस्तारित विशेषताओं का उपयोग कर सकते हैं। सबसे बड़ी समस्या शायद फ़ाइल ब्राउज़र को पैच करना होगा।


1
"कुछ भी नहीं है एक कभी बदलते फ़ाइल सिस्टम संरचना से भी बदतर" एक को छोड़कर कि बदलने के लिए मना कर दिया जब भी संरचना समझ में नहीं आता है।
जम्फिशर

1
"वर्णनात्मक और सुसंगत निर्देशिका नामों का उपयोग करें" - बिल्कुल आवश्यक, हाँ। दुर्भाग्य से वर्णनात्मकता और संक्षिप्तता के बीच एक संघर्ष है - कोई भी / srv / सभी-पदानुक्रमित-डेटा / सुलभ-केवल-कार्यालय-और-व्यवस्थापक / पत्र-लेकिन-नहीं-सार्वजनिक में एक फ़ाइल का पथ टाइप करना चाहता है -नोटिसेस / शैक्षणिक-वर्ष -2009 / ... वगैरह।
jameshfisher

"अपनी निर्देशिका संरचना के लिए एक दस्तावेज लिखें" - यह भी एक महान विचार है। यह अनिवार्य रूप से मैं क्या सुझाव दे रहा हूं; सिर्फ यह कि दस्तावेज अखंड के बजाय वितरित किया जाएगा।
jameshfisher

"श्रेणियों (= निर्देशिकाओं, फ़ोल्डर) का विचार स्केल नहीं करता है" - सच्चा-ईश, कभी-कभी इसे छोड़कर। कहो, बड़े सॉफ़्टवेयर स्रोत पेड़ ( git.kernel.org/?p=linux/kernel/git/next/linux-next.git=a=tree )
jameshfisher

"एक .filingफ़ाइल के बजाय आप उस जानकारी को एक वैकल्पिक डेटा स्ट्रीम में संग्रहीत कर सकते हैं (हाँ, फ़ोल्डर्स में ADS भी हो सकते हैं)। आप लिनक्स और OSX पर विस्तारित विशेषताओं का उपयोग कर सकते हैं।" संभव है, मैं कल्पना करता हूं, लेकिन मुझे लगता है कि पोर्टेबिलिटी और पारदर्शिता घट जाती है। क्या होगा अगर मैं सब कुछ एक git रेपो में रखना चाहता हूँ? प्लेनटेक्स्ट फाइलों का इस्तेमाल डायरेक्टरी-स्पेसिफिक कॉन्फिगरेशन (जैसे htaccess) के लिए किया जाता है, तो डॉक्यूमेंटेशन भी क्यों नहीं?
jameshfisher

2

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

दी, यह एक फाइलसिस्टम-आधारित समाधान नहीं है, लेकिन जब तक कि सभी फाइलसिस्टम कुछ सामान्य, वसाबी (या इसका अपना कार्यान्वयन) का समर्थन नहीं करते, तब तक यह सबसे अच्छा विकल्प हो सकता है।


1

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

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

आप अपने ओएस को निर्दिष्ट नहीं करते हैं, लेकिन अल्फ्रेस्को जैसे उत्कृष्ट (और मुफ्त) उत्पाद हैं जो शायद आपके वर्तमान सेटअप से बेहतर सेवा प्रदान कर सकते हैं।


मैंने विभिन्न सीएमएस के साथ डब किया है, लेकिन पाया है कि पोर्टेबिलिटी, सादगी, और पारदर्शिता का भुगतान करने के लिए भारी लागत होती है, जब सबसे अनुकूल सीएमएस की तुलना में वहाँ: निर्देशिका पेड़। अधिकांश डेटा जिन्हें मैंने प्रबंधित किया है, वे पदानुक्रम में फिट हो सकते हैं। अंतिम उपाय के रूप में, सहानुभूति होती है। और निर्देशिका संरचना कभी-कभी एकमात्र समाधान होती है: जैसे सॉफ्टवेयर विकास में, स्रोत कोड आधार पर होता है, एक निर्देशिका ट्री। (उस तरह की डॉक्यूमेंटिंग डाइरेक्टरीज़ का मतलब आम तौर पर एक कठोर और गूढ़ स्कीमा से चिपकना होता है, जो अंततः टूट जाता है। मुझे लगता है कि मेरा समाधान यहां भी मदद कर सकता है।)
jameshfisher

जैसा कि मैंने कहा, आपके विचार में योग्यता है, लेकिन मुझे लगता है, दूसरे पोस्टर के लेखक की तरह, कि यह किसी दिए गए स्तर से परे नहीं हो सकता। आप स्रोत कोड का उल्लेख करते हैं, लेकिन यह एक बहुत ही विशिष्ट मामला है - और जब आप इसमें कोड जोड़ते हैं तो आप मौजूदा निर्देशिकाओं में नहीं देखते हैं कि यह "फिट" कहां है। एक सीएमएस आमतौर पर आपको सामान को टैग करने की क्षमता देता है ताकि आपके पास "निर्देशिका" (फ़ोल्डर, रिक्त स्थान, पृष्ठ) हो जो आपके समाधान की तरह काम करते हैं, साथ ही एक टैगिंग प्रणाली है जो लोगों को "सही" निर्देशिका की तलाश किए बिना सामान खोजने की अनुमति देता है। यह सहानुभूति की तुलना में अधिक लचीला है और त्रुटियों के लिए कम है, IMHO।
p.marino

1

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

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

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

इसके अतिरिक्त यूजर इंटरफेस को बदले बिना फाइलसिस्टम पदानुक्रम संरचना को बदलना भी संभव होगा।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.