Yandex.Maps API के रचनाकारों से बुरी सलाह। हर चीज को बुरा कैसे बनाया जाए

अगर आपका पीछा कर रहा है

बहुत सारे लोग

उनसे विस्तार से पूछें

वे कैसे परेशान हैं?

सभी को सांत्वना देने का प्रयास करें।

सभी को सलाह दें

लेकिन एक ही समय में धीमा

कुछ भी नहीं करने के लिए बिल्कुल।

जी। ओस्टर

आज अद्भुत वसंत का दिन है। और न केवल क्योंकि यह वसंत है और बहुत जल्द किसी को आलू खोदने के लिए देश जाना होगा। और क्योंकि आज Yandex.Maps API का संस्करण 2.1 बीटा संस्करण बनना बंद हो गया है और मुख्य बन गया है ।



इस घटना के लिए, हमने प्रलेखन को पूरी तरह से अपडेट किया, सैंडबॉक्स में नए उदाहरण जोड़े, और इस लेख को लिखा। इस बार हमने केवल संस्करण 2.1 के बारे में बात नहीं करने का फैसला किया, क्योंकि हमने पहले ही बीटा लॉन्च के दौरान इसके बारे में पर्याप्त बात की थी । आइए सामान्य रूप से Yandex.Maps API का उपयोग करने के बारे में बात करते हैं।



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



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

किसी भी स्थिति में उपयोगकर्ता समझौते को न पढ़ें

विंडोज का उपयोग करने के सदियों पुराने अनुभव ने हमें कुछ सिखाया है। हम उपयोगकर्ता समझौतों को पढ़ने की कोशिश भी नहीं कर रहे हैं। हम साहसपूर्वक कहते हैं: "मैं सब कुछ से सहमत हूँ" - और हमें लगता है कि कर्म प्रतिशोध हमें कभी नहीं पछाड़ेंगे - "क्या वे मूर्ख हैं? "मेरे सिलिकॉन वैली से गस ख्र्सटाल्नी को जाने के लिए मुझे अपने समुद्री डाकू विंडोज का उपयोग करने के लिए मना करना चाहिए?"

यदि आप Yandex.Maps API का उपयोग करते हैं, तो आपको उसी रणनीति का पालन करना चाहिए।



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



इसलिए, काम शुरू करने से ठीक पहले, अपने आप को एक सेटिंग दें - यदि आपने समझौते को नहीं पढ़ा है, तो आपको मूल रूप से सीमाओं के बारे में पता नहीं है और कार्टोग्राफी की दुनिया आपके लिए असीमित है। बेशक, इसमें एक माइनस है - उल्लंघन का पता चलने पर एपीआई को आपकी साइट पर प्रतिबंधित किया जा सकता है। लेकिन, जैसा कि आप जानते हैं, समस्याओं को हल करने की आवश्यकता है क्योंकि वे उपलब्ध हो जाते हैं, इसलिए हम चुपचाप आगे बढ़ रहे हैं।



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

किसी भी प्रकार के प्रलेखन को पढ़ने से बचें।

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



इसलिए, जहां आपको आवेदन विकास शुरू करने से पहले नहीं देखना चाहिए:

• डेवलपर गाइड
• सैंडबॉक्स उदाहरण
• कार्यक्रम इंटरफ़ेस संदर्भ

जावास्क्रिप्ट जानने के बारे में चिंता न करें।

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



आदर्श विकल्प PHP का उपयोग करके जावास्क्रिप्ट निर्माणों को प्रिंट करना है। मैं एक उदाहरण दूंगा:

<?php foreach($maps as $map): ?> myPlacemark = new ymaps.Placemark(["<?php echo $map['lantitude']; ?>" ,"<?php echo $map['longitude']; ?>" ]); myMap.geoObjects.add(myPlacemark); <?php endforeach;?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

देखिए कि हम कितनी अच्छी तरह से जावास्क्रिप्ट के साथ चले गए!



यह दृष्टिकोण आपको कई अप्रिय परिणामों से बचने की अनुमति देता है।

• आपका एप्लिकेशन उपयोगकर्ता के जीवन के अर्थ के बारे में सोचने के लिए समय देने के लिए धीरे-धीरे चलेगा।
• आपके कोड को ऑबफैक्शन की आवश्यकता नहीं होगी, क्योंकि यह शुरू से ही काफी भ्रमित है।
• पृष्ठ कोड ब्राउज़र द्वारा कैश नहीं किया जाएगा, लेकिन सर्वर पर हर बार फिर से जेनरेट किया जाएगा।

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



यदि आप एक जावास्क्रिप्ट अनुप्रयोग विकसित करने का निर्णय लेते हैं तो एक पुस्तक पढ़ने लायक नहीं है:

संरचना कोड से बचें

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



यह कई कारणों से नहीं किया जाना चाहिए:

• मॉड्यूलर कोड को पढ़ना मुश्किल है क्योंकि कमांड ऑर्डर से बाहर हैं।
• वास्तुकला के विकास में बहुत समय लगता है।
• कार्ड का उपयोग करने वाला एक आवेदन केवल आपके समय और ध्यान के योग्य नहीं है। बिंदु।

मैप्स का उपयोग करके एप्लिकेशन विकसित करते समय बचने वाली बातें:

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

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

 //   . ymaps.modules.define('CustomModule', function (provide) { var CustomModule = function (defValue) { this.field = defValue; }; provide(CustomModule); }); //  . ymaps.modules.require(['CustomModule']) .spread( function (CustomModule) { // ... }, this );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



ऐसी पुस्तकें जो आपको सही कोड लिखने से रोक सकती हैं, कपटी लोगों द्वारा लिखी गई हैं। उनके मूल्य प्रणाली को उल्टा कर दिया जाता है। दुश्मन को व्यक्तिगत रूप से जाना जाना चाहिए, यहां कुछ संभावित खतरनाक प्रकाशन हैं:

सब कुछ पहले से तैयार रखें

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



यहां एक दुखद उदाहरण दिखाया गया है कि कैसे मांग पर एक गुब्बारे में डेटा लोड किया जाए। यहां एक और दुखद उदाहरण दिखाया गया है कि मांग पर एक नक्शा कैसे बनाया जाए। और क्या केवल इन डेवलपर्स के लिए गिर नहीं है ...

स्टॉक के साथ डाउनलोड करें

एक एपीआई बहुत सारे कोड मॉड्यूल और पैकेज में टूट गया है। अपनी साइट विकसित करने के बाद, आपको एक और महत्वपूर्ण प्रश्न हल करने की आवश्यकता है: आपकी साइट से कनेक्ट करने के लिए कौन सा एपीआई कोड?



यहाँ यह उन मामलों को याद करने के लिए नहीं होगा जब आपने कोला के लिए एक मित्र को भेजा था, और वह एक लाया। कोड लोड करने के लिए बिल्कुल वही नियम काम करता है। संपूर्ण API कोड को डाउनलोड करना बेहतर है - आपको कभी नहीं पता कि क्या काम आता है। संस्करण 2.0 में, डेवलपर्स ने पैकेज बनाए जो उपयोगकर्ता गलती से उपयोग करना शुरू कर सकते हैं यदि वे बिना किसी सैंडबॉक्स से एक उदाहरण की नकल करते हैं।







ऐसी त्रुटियों से कैसे बचें? संस्करण 2.0 का उपयोग करते समय, लोड करने योग्य मॉड्यूल के किसी भी संयोजन को package.full में बदला जाना चाहिए। इस दृष्टिकोण के साथ, उपयोगकर्ता को बहुत अधिक कोड मिलेगा, जो अच्छा है।



संस्करण 2.1 में, डेवलपर्स, दुर्भाग्य से, पता चला कि लोगों ने उकसाने में नहीं दिया और पूरे एपीआई को लोड किया। इसलिए, संस्करण 2.1 में, पैकेजों को पूरी तरह से रद्द कर दिया गया था, और package.full को अब उन भागों में विभाजित किया गया है जो आवश्यकतानुसार अतुल्यकालिक रूप से लोड किए जाते हैं।

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







प्रोग्रामिंग अच्छी तरह से कठिन हो रही है।

नियंत्रण जोड़ें

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







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



संस्करण २.१ ने हमें फिर से बैंडबाजे पर खड़ा कर दिया। इसका कम नियंत्रण है (खलनायक ने एक न्यूनतम आकार देखा), वे मानचित्र पर डिफ़ॉल्ट रूप से स्थापित होते हैं और एक छोटे से नक्शे पर एक छोटे आकार के ढह जाते हैं।







अपने लिए देखें - कुछ बटन हैं, वे खुद छोटे हैं। नक्शा आमतौर पर नग्न है! सामान्य तौर पर, 2.1 आमतौर पर उपयोग नहीं करना बेहतर होता है।

उपयोगकर्ता को दिखाएं कि उसका ब्राउज़र कितना कमजोर है।

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



ब्राउज़रों की खामियों को छिपाने की कोशिश करने वाले डेवलपर्स बहुत ही परिष्कृत तरीके से अपनी खामियों का सामना करते हैं:

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

जियोकोडर अनुरोधों को बचाने की कोशिश न करें

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



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



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







और यह आलस्य नहीं था ...

तकनीकी सहायता से रोटी न लें

कुछ बिंदु पर, आप Yandex.Maps API तकनीकी सहायता सेवा के साथ चैट करने के लिए एक अजीब अनूठा इच्छा महसूस कर सकते हैं। इस घटना को गंभीरता से लेने की जरूरत है, न कि किसी भी तरह से।



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



यहाँ एक क्लब से संपर्क करने का एक अच्छा उदाहरण है:







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



टेक सपोर्ट या एक क्लब से संपर्क करने से बचने के लिए चीजें:

• समस्या का विस्तृत विवरण।
• कोड लाना जिसके साथ आप बग को दोहरा सकते हैं।
• उस पृष्ठ से लिंक करें जहां बग खेला जाता है।

यदि आप विकास क्लब को समस्या के बारे में लिखना चाहते हैं, तो आपको खोज का उपयोग नहीं करना चाहिए, FAQ का उत्तर पढ़ें और अपनी समस्या का समाधान खोजने के लिए किसी अन्य तरीके से प्रयास करें। सोचिये - यदि सभी को प्रश्नों के उत्तर स्वयं मिल जायेंगे, तो तकनीकी सहायक कार्यकर्ता क्या करेंगे?

निष्कर्ष

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



हमारे लेख को दिल पर न लें, अपनी परियोजनाओं में सुधार करें, हमें शुभकामनाएं और नाराज़गी भेजें। हम आपको सब कुछ समझाएंगे और आपको बताएंगे, भले ही सब कुछ टूट गया हो और कुछ भी काम नहीं करता हो)