किसी साइट के लिए एक संयुक्त उपयोगकर्ता स्क्रिप्ट कैसे बनाएं?

मान लीजिए कि एक स्क्रिप्ट और शैलियों की मदद से, हमें एक साइट के लिए उपयोगकर्ता स्क्रिप्ट के संग्रह का हल मिला, जिसका विचार लंबे समय से हवा में है और कई लोगों द्वारा इच्छाओं के रूप में व्यक्त किया गया था, टिप्पणियों में उपयोगकर्ता शैलियों के बारे में लगभग हर लेख में। वर्ष की शुरुआत में, इस तरह के समाधान का एक कार्यान्वयन भी था - github.com/silentroach/habrafix , जो स्पष्ट रूप से, 3 अक्टूबर 2011 के अनुसार भी काम नहीं करता है। एक सरल प्रारंभिक रूप में, समाधान को बनाए रखना मुश्किल होगा - एक व्यक्ति को स्क्रिप्ट का निर्माण करना होगा, सभी ब्राउज़रों का समर्थन करना होगा, अन्य उपयोगकर्ताओं के अनुरोध पर नई सुविधाओं को जोड़ना होगा, या, सबसे अच्छा, कांटे पर विचार करना और उनकी कार्यक्षमता को संयोजित करना होगा।

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

आइए देखें कि 10/03/2011 के बाद कितनी स्क्रिप्ट्स बरामद हुईं। बस एक खोज करते हैं: usercripts.org/scripts/search?q=habrahabr&submit=Search , खोज करने के लिए अन्य शब्द "habr", "habr" हैं। निर्दिष्ट तिथि (6 टुकड़े) के ऊपर सब कुछ, फिर स्क्रिप्ट लेखक विनाश के बाद करने में सक्षम थे। बाकी लिपियों में से अधिकांश काम नहीं करते हैं (12 टुकड़े केवल 2011 के लिए, 16 के लिए 2010, पहले वाले के लिए एक और 20), हालांकि प्रत्येक, ज़ाहिर है, निर्दिष्ट हेरफेर और परीक्षण के साथ बहाल किया जा सकता है। लेकिन अधिकांश लेखक, जाहिर है, अब समाधान या इसके प्रकाशन से निपटना नहीं चाहते हैं। समझने में आसान क्या है - पटकथा, सबसे अधिक बार, विचार से प्रेरणा का परिणाम था, और पास किए गए समाधानों की वापसी हमेशा दिलचस्प और आवश्यक नहीं होती है।

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

प्रणालीगत समस्याओं के आसपास जाने के लिए, आपको प्रणालीगत निर्णय लेने की आवश्यकता है। कौन से हैं? हम "बुद्धिशीलता" के क्रम में सूचीबद्ध करते हैं।

* एक और "हब्र"

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

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

वर्णित योजना Reddit.com में बहुत से लोग, digg.com के एक मिश्रण के साथ, RSS की एक तृतीय-पक्ष साइटों (उदाहरण के लिए, Google रीडर की तरह) और अन्य संसाधन के फीड के साथ, सावधानी से नशे में हैं। ठीक है, यह योजना व्यवहार्य है, उत्साही लोगों के एक समूह की आवश्यकता है (एक रिकॉर्डिंग की घोषणा की गई है, और इसके अलावा, हैबे पर पहले से ही लोग हैं, जिन्होंने मुझे समान विचारों वाले समूह के साथ संपर्क किया है ताकि मैं सदस्य बन जाऊं। शायद यह विचारों और संसाधनों के संयोजन और कुछ बनाने के लायक है। समूह)।

लेकिन प्रस्तावों का यह समूह सीमित नहीं है, लेख इस बारे में नहीं है, बल्कि एक गहन सार के बारे में है। हम विभिन्न लेखकों से अधिक व्यवहार्य उपयोगकर्ता-स्क्रिप्ट समर्थन को कैसे लागू कर सकते हैं?

* प्लगिन और बुनियादी कार्यों के लिए समर्थन के साथ उपयोगकर्ता स्क्रिप्ट

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

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

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

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

* एक और तरीका - सिमेंटिक स्क्रिप्ट

अंत में, एक और तरीका काम के "साइसेफस" प्रकृति को कमजोर करने के लिए देखा जाता है - तैयार मूल साइट का उपयोग न्यूनतम और संक्षेप में किया जाना चाहिए। यही है, इससे सामग्री लेने के लिए नहीं + लेआउट, जैसा कि सभी स्क्रिप्ट करते हैं, लेकिन केवल सामग्री। फिर हमें कई प्रकार के मंत्रियों से छुटकारा मिलता है:

*) लेआउट से स्वतंत्र - एक बड़ी राहत। केवल पार्सर लेआउट पर निर्भर करेगा, कहीं जाना नहीं है, लेकिन यह आमतौर पर काफी सरल है। फिर, यदि लेआउट बदलता है, तो सब कुछ (या जो बदल गया है) पहले ढह जाता है, लेकिन पार्सर की मरम्मत के बाद, प्रस्तुति बनाने वाले सभी स्क्रिप्ट और प्लगइन्स काम करना जारी रखेंगे, क्योंकि वे अपने स्वयं के स्थिर लेआउट पर होंगे।

*) सर्वोत्तम प्रथाओं का उपयोग अन्य सामग्री के लिए किया जाता है - बस किसी अन्य साइट के लिए एक पार्सर लिखें - और हमारे पास परिणामी डेटा संरचना के लिए पहले की गई सभी सर्वोत्तम प्रथाओं का काम है।

*) यह आरएसएस की तुलना में अधिक जटिल है, लेकिन मुख्य आपूर्तिकर्ता - साइट को तोड़ने के मामले में आरएसएस एक विकल्प, एक आधिकारिक सामग्री प्रदाता हो सकता है।

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

डाउनसाइड क्या हैं?
*) सभी ajax अनुरोधों को अपनी स्क्रिप्ट में दोहराया जाना चाहिए या डेटा विनिमय के लिए साइट स्क्रिप्ट के लॉन्च का उपयोग करना चाहिए।
*) प्लग-इन डेवलपर को पृष्ठ के साथ काम करने की आवश्यकता नहीं है (जो सरल है - Ctrl-U पर देखा गया है, और सब कुछ दिखाई दे रहा है), लेकिन डेटा श्रेणियों के साथ: संदेश, लेखक, तिथि, उत्तर, लेखक, तिथि, रेटिंग, मतदान के लिए साइट कार्य, संदेश भेजना, आदि। .d .. यह अधिक जटिल है (पार्सर के लेखक के लिए भी), लेकिन यह लेआउट से स्वतंत्रता के एक विशाल प्लस के साथ ओवरलैप करता है, बशर्ते कि कोई पार्सर हो। इसका मतलब है कि 2-3 साल पहले लिखा गया प्लगइन काम करेगा, अगर यह प्रस्तुति की चिंता करता है, और 80-90% प्लगइन्स इस तरह हैं। लेकिन डेटा के साथ काम करने के कुछ कार्यों को साइटों से भी अलग किया जा सकता है, ताकि ऑपरेशन "प्रतिक्रिया भेजें" या मूल्यांकन भेजना कार्यान्वयन पर निर्भर न हो।
*) पार्सर डेवलपर को सिस्टम के माध्यम से अच्छी तरह से सोचने की जरूरत है ताकि यह प्लगइन डेवलपर्स के लिए सरल बना रहे। डेवलपर आधार के विस्तार के लाभों से अधिक।

यह, तीसरा विचार अधिक आशाजनक लगता है, इसलिए इसने कलाकारों और प्रायोजकों के एक समूह की भी घोषणा की।

अगले नकारात्मक कारकों को हटाने के लिए परिणामी प्रणाली को कैसे विकसित किया जाए, इस पर अन्य विचार हैं - हटाए गए संदेश और लेख, सर्वर क्रैश, लेकिन वे स्क्रिप्ट की चर्चा से परे जाते हैं।

संक्षेप में देना

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

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

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

कुल मिलाकर, सभी 3 क्षेत्र प्रासंगिक हैं और एक दृष्टिकोण व्यक्त करते हैं जो सामाजिक नेटवर्क में डेटा प्रस्तुति की गुणवत्ता पर अधिक केंद्रित है।