🥇इंटरफ़ेस डेवलपमेंट स्कूल: मिन्स्क के लिए कार्यों का विश्लेषण और मॉस्को में एक नया सेट

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

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

मॉस्को में पंजीकरण के उद्घाटन के अवसर पर, हम यहां मिन्स्क में - पिछले स्कूल के परिचयात्मक कार्यों का विश्लेषण प्रकाशित कर रहे हैं।

यदि आप एसआरआई असाइनमेंट के इतिहास का पता लगाएं, तो साल-दर-साल हमने एक प्रोग्रामर के लिए तीन महत्वपूर्ण कौशल का परीक्षण किया:

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

प्रत्येक कार्य के विश्लेषण में हम आपको न केवल सही प्रक्रिया के बारे में बताएंगे, बल्कि सामान्य गलतियों के बारे में भी बताएंगे।

कार्य 1: पोर्टफोलियो

पहले कार्य पर Yandex.Collections डिज़ाइनर एलेक्सी चेरेनकेविच, जो लेआउट करना जानते हैं, और उनके सेवा सहयोगी, इंटरफ़ेस डेवलपर सर्गेई सैमसनोव द्वारा काम किया गया था।

शर्त

एक पोर्टफोलियो वेबसाइट बनाएं: हमें अपने बारे में, अपने काम के बारे में और स्कूल से अपनी अपेक्षाओं के बारे में बताएं। साइट को यथासंभव प्रस्तावित लेआउट के अनुरूप होना चाहिए (लेआउट के लिंक: 1000px, 600px, 320px, विनिर्देश). हम केवल लेआउट में रुचि रखते हैं, इसलिए कृपया जावास्क्रिप्ट का उपयोग न करें।

जाँच करते समय हम इस बात का ध्यान रखेंगे:

इंडेंटेशन आकार, रंग शुद्धता, फ़ॉन्ट शैली, फ़ॉन्ट आकार;

अर्थपूर्ण लेआउट;

तत्वों की विभिन्न अवस्थाओं की उपस्थिति: कर्सर मँडराते समय बटन और लिंक प्रदर्शित करना, सक्रिय इनपुट फ़ील्ड को हाइलाइट करना, आदि;

क्रॉस-ब्राउज़र संगतता (लोकप्रिय ब्राउज़रों के नवीनतम संस्करणों में परीक्षण किया गया)।

फायदा ये होगा:

आधुनिक सीएसएस समाधानों का उपयोग: फ्लेक्सबॉक्स, ग्रिड, आदि;

अनुकूली लेआउट;

प्री- और (या) पोस्ट-प्रोसेसर का उपयोग, असेंबली, मिनिफिकेशन, आउटपुट कोड का अनुकूलन;

HTML फॉर्म सत्यापन, शैलीबद्ध फ़ाइल अपलोड बटन।

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

असाइनमेंट में प्रस्तावित लेआउट न केवल मोबाइल उपकरणों, टैबलेट और डेस्कटॉप के लिए स्क्रीन के साथ थे, बल्कि वास्तविक विशिष्टताओं के साथ भी थे।

पहले कार्य की जाँच के परिणाम में यथासंभव निष्पक्षता लाने के लिए, इस जाँच के लिए बहुत सारे मानदंड थे।

मानदंड

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

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

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

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

कार्यशील स्लाइडर. असाइनमेंट में हमने लिखा था कि JS का उपयोग नहीं किया जा सकता है। यहां समस्याओं को हल करने की क्षमता का परीक्षण किया गया - एक गुच्छा का उपयोग करके एक स्लाइडर बनाया जा सकता है और . सारा जादू चयनकर्ता स्तर पर होता है #बटन-एन:चेक ~ .स्लाइडर-इनर .स्लाइडर-स्लाइड्स। जब हम किसी एक इनपुट चेकबॉक्स पर क्लिक करते हैं, तो यह चेक की गई स्थिति में चला जाता है। हम इसका लाभ उठा सकते हैं और हमें जिस अनुवाद की आवश्यकता है उसे स्लाइड वाले कंटेनर में असाइन कर सकते हैं: ट्रांसफॉर्म: ट्रांसलेशन (-33%)। आप स्लाइडर का कार्यान्वयन देख सकते हैं यहां.

ड्रॉपडाउन सूचियाँ. यहाँ यह सब भी नीचे आ गया और एक समान चयनकर्ता: .accordion-item इनपुट:चेक ~ .accordion-item__content। आप कार्यान्वयन देख सकते हैं यहां.

:hover, :active और :focu* स्थितियों की उपलब्धता. एक बहुत ही महत्वपूर्ण बिंदु. इंटरफ़ेस के साथ बातचीत के दौरान आराम इस पर निर्भर था। उपयोगकर्ता को हमेशा अपने कार्यों पर प्रतिक्रिया प्राप्त करनी चाहिए। प्रश्नावली के साथ बातचीत के दौरान इस आइटम की जाँच की गई। यदि मैंने "मुझे कॉल करें" बटन पर क्लिक किया और दृश्यमान रूप से कुछ नहीं हुआ (भले ही अनुरोध भेजा गया था), तो यह बुरा है, क्योंकि तब मैं इसे बार-बार क्लिक करूंगा। परिणामस्वरूप, दस अनुरोध भेजे जाएंगे और मुझे दस बार वापस बुलाया जाएगा। हमें यह नहीं भूलना चाहिए कि मोबाइल उपकरणों में माउस नहीं होता, यानी होवर नहीं होना चाहिए। और एक और बात जिसने उन लोगों को प्रभावित नहीं किया जिन्होंने शब्दार्थ के बारे में बात पूरी की। यदि आपका नियंत्रण एक इंटरैक्टिव तत्व नहीं है, तो जब आप उस पर होवर करेंगे, तो कर्सर मानक बना रहेगा। यह बहुत गन्दा दिखता है, भले ही आपने होवर पर प्रतिक्रिया लिखी हो। कर्सर को कम न समझें: सूचक।

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

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

प्रपत्र सत्यापन. बस फॉर्म के प्रत्येक इनपुट में आवश्यक विशेषता जोड़ना आवश्यक था। हमने उन लोगों के लिए अंक जोड़े जिन्होंने ईमेल फ़ील्ड को ईमेल के रूप में मान्य किया।

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

क्रॉस-ब्राउज़र अनुकूलता. हमने जाँच की कि आधुनिक ब्राउज़र के दो नवीनतम संस्करणों (IE के बिना - प्रतिभागी भाग्यशाली थे) के साथ-साथ iPhone पर Safari और Android पर Chrome में सब कुछ ठीक था।

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

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

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

कार्य 2: परिवहन मार्ग

कार्य के लेखक खोज इंटरफ़ेस समूह डेनिस बाल्यको के प्रमुख हैं।

शर्त

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

फ़ंक्शन हस्ताक्षर:
const solution = function(graph, start, finish)  {
    // Ваше решение
} 
उदाहरण इनपुट डेटा:
const graph = {
  start: { A: 50, B: 20 },
  A: { C: 40, D: 20 },
  B: { A: 90, D: 90 },
  C: { D: 160, finish: 50 },
  D: { finish: 20 },
  finish: {}
};
const start = 'start';
const finish = 'finish'; 
उदाहरण आउटपुट:
{
    distance: 90,
    path: ['start', 'A', 'D', 'finish']
} 
नोट: समाधान ढांचा src/फ़ोल्डर में है, अपना समाधान समाधान.जेएस में रखें।

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

मानदंड

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

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

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

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

सही समाधान:

const solution = function(graph, START, FINISH)  {
    // Всё не бесплатно в этом мире
    const costs = Object.assign({[FINISH]: Infinity}, graph[START]);

    // Первая волна родительских нод
    const parents = { [FINISH]: null };
    Object.keys(graph[START]).reduce((acc, child) => (acc[child] = START) && acc, parents)

    const visited = [];
    let node;

    // Ищем «дешёвого» родителя, отмечаем пройденные
    do {
        node = lowestCostNode(costs, visited);
        let children = graph[node];
        for (let n in children) {
            let newCost = costs[node] + children[n];

            // Ещё не оценена или нашёлся более дешёвый переход
            if (!costs[n] || costs[n] > newCost) {
                costs[n] = newCost;
                parents[n] = node;
            }
        }
        visited.push(node);
    } while (node)

    return {
        distance: costs[FINISH],
        path: optimalPath(parents)
    };

    // Возврат назад по самым «дешёвым» родителям
    function optimalPath(parents) {
        let optimalPath = [FINISH];
        let parent = parents[FINISH];
        while (parent && parent !== START) {
            optimalPath.push(parent);
            parent = parents[parent];
        }
        optimalPath.push(START);
        return optimalPath.reverse();
    }

    // Минимальная стоимость из текущей ноды среди непросмотренных
    function lowestCostNode(costs, visited) {
        return Object.keys(costs).reduce((lowest, node) => {
            if (lowest === null || costs[node] < costs[lowest]) {
                if (!visited.includes(node)) {
                    lowest = node;
                }
            }

            return lowest;
        }, null);
    };
};

कार्य 3: ईवेंट कैलेंडर

इसे इंटरफ़ेस डेवलपर्स सर्गेई कज़ाकोव और अलेक्जेंडर पॉडस्क्रेबकिन द्वारा तैयार किया गया था।

शर्त

अपना शेड्यूल प्रदर्शित करने के लिए एक लघु-कैलेंडर लिखें। आप अपनी पसंद का कोई भी शेड्यूल ले सकते हैं। उदाहरण के लिए, 2019 में फ्रंटएंड सम्मेलनों का शेड्यूल।

कैलेंडर एक सूची की तरह दिखना चाहिए. कोई अन्य डिज़ाइन आवश्यकताएँ नहीं हैं. 3, 7 और 14 दिन पहले ईवेंट अनुस्मारक सेट करना संभव बनाएं। इंटरनेट से पहली बार डाउनलोड करने के बाद, कैलेंडर खुल जाना चाहिए और ऑफ़लाइन कार्य करना चाहिए।

उपयोगी संसाधन

फ्रंटएंड सम्मेलन कार्यक्रम:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

सेवा कर्मी:
डेवलपर.mozilla.org/ru/docs/Web/API/Service_Worker_API/Using_Service_Workers
डेवलपर्स.google.com/web/fundamentals/Primers/service-workers

सूचनाएं एपीआई:
डेवलपर.mozilla.org/ru/docs/Web/API/Notifications_API

तीसरा कार्य परीक्षण के लिए सबसे दिलचस्प था, क्योंकि बहुत सारे संभावित समाधान थे, प्रत्येक का अपना समाधान था। हमने जाँच की कि उम्मीदवार अपरिचित तकनीकों को कैसे संभालता है - क्या वह शोध करना जानता है, क्या वह अपने समाधानों का परीक्षण करता है।

मानदंड

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

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

त्रुटियों के बिना सेवा कार्यकर्ता पंजीकरण और पहले डाउनलोड के बाद ऑफ़लाइन काम करें। यहाँ एक उदाहरण है। प्रथम बूट पर शेड्यूल कैशिंग वाला सेवा कर्मी। सेवा कर्मियों, उनकी क्षमताओं और उनके साथ काम करने के तरीकों (कैश के साथ काम करने की रणनीतियाँ, ऑफ़लाइन काम करने की रणनीतियाँ) के बारे में विवरण यहां पाया जा सकता है।

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

डेस्कटॉप पर एक आइकन रखने की क्षमता (पीडब्ल्यूए)। हमने फ़ाइल की उपस्थिति की जाँच की manifest.json सही चिह्नों के साथ. कुछ लोगों ने यह फ़ाइल बनाई (या इसे CreateReactApp में जेनरेट करके छोड़ दिया) - लेकिन सही आइकन नहीं जोड़े। फिर, इंस्टॉल करने का प्रयास करते समय, "एक अलग आइकन की आवश्यकता है" जैसी त्रुटि उत्पन्न हुई।

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

कंसोल त्रुटियाँ. यदि कंसोल में कोई संकेतक था कि कुछ गलत था, और प्रतिभागी ने उस पर ध्यान नहीं दिया, तो हमने अंक काट लिए।

परिणाम

प्रतिभागियों के निर्णयों में क्या मज़ेदार है:

एक प्रश्नावली में निम्नलिखित पाठ था: “एक प्रोग्रामर मित्र ने मुझे एक रिएक्ट एप्लिकेशन तैयार करने में मदद की। मैंने उस पर कैसे और क्यों जैसे सवालों की बौछार कर दी और उसने मुझे बताया। मुझे यह वाकई पसंद आया, मैं इसके बारे में और जानना चाहता हूं।” हम पूरे दिल से इस एप्लिकेशन का समर्थन कर रहे थे, लेकिन दुर्भाग्य से, उम्मीदवार का मित्र एप्लिकेशन को काम करने में बहुत मददगार नहीं था।
एक उम्मीदवार ने GitHub को एक लिंक भेजा, जहां RAR संग्रह स्थित था - इस पर टिप्पणी करना मुश्किल है। 🙂
एक अन्य उम्मीदवार ने, सॉल्यूशन.जेएस फ़ाइल की पहली पंक्ति पर टिप्पणी में, ईमानदारी से स्वीकार किया कि उसने एल्गोरिदम की नकल की है।

हमें 76 उम्मीदवारों से आवेदन प्राप्त हुए और 23 लोगों का चयन किया गया। हमें न केवल मिन्स्क से, बल्कि मॉस्को, सेंट पीटर्सबर्ग और यहां तक कि तातारस्तान से भी प्रश्नावली भेजी गईं। कुछ लोगों ने अपने वर्तमान पेशे से हमें आश्चर्यचकित कर दिया: उनमें से एक फोरेंसिक विशेषज्ञ है, और दूसरा मेडिकल छात्र है।

परिणाम कार्यों को पूरा करने में सफलता दर का एक दिलचस्प वितरण था। प्रतिभागियों ने पहला कार्य औसतन 60% से पूरा किया, दूसरा 50% के औसत से, और तीसरा सबसे कठिन निकला और 40% के औसत से पूरा किया।

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

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

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

स्रोत: www.habr.com

इंटरफ़ेस डेवलपमेंट स्कूल: मिन्स्क के लिए कार्यों का विश्लेषण और मॉस्को में एक नया सेट

कार्य 1: पोर्टफोलियो

शर्त

मानदंड

कार्य 2: परिवहन मार्ग

शर्त

मानदंड

कार्य 3: ईवेंट कैलेंडर

शर्त

उपयोगी संसाधन

मानदंड

परिणाम

एक टिप्पणी जोड़ें उत्तर रद्द