SberTech के एक कर्मचारी की आंखों के माध्यम से HeisenBug

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

HeisenBug के बारे में जानकारी

हाइजेनबग - परीक्षण विशेषज्ञों के लिए तकनीकी सम्मेलन। यह मुख्य रूप से परीक्षकों, सॉफ्टवेयर विकास इंजीनियरों के लिए और स्वचालित और लोड परीक्षण के विशेषज्ञों में रुचि रखता है। आयोजक JUG.RU टीम हैं, जिसके पीछे जोकर, होलीजेएस, स्मार्टडाटा, देवओप्स, डॉटनेक्स्ट, मोबियस जैसे सम्मेलन हैं।

स्थान

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

कार्यक्रम

कार्यक्रम यहां पाया जा सकता है । मैं यह नोट करना चाहता हूं कि JUG.RU हमेशा अतिरिक्त पानी के बिना और जाने-माने विदेशी विशेषज्ञों के साथ कार्यक्रम को व्यावहारिक बनाने का प्रयास करता है। रिपोर्ट को प्रतीकों में विभाजित किया गया है:



यदि यह पहली बार हेइज़ेनबाग में एक स्पीकर बनने की योजना बना रहा है, तो स्पीकर के मेमो को देखें - इसमें काफी उपयोगी जानकारी है।

संचार और स्वयंसेवा

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

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

कंपनी खड़ी है

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



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



कई कंपनियाँ विशेषज्ञों का बेजा शिकार करती हैं, रिक्तियों का वर्णन करने वाली पुस्तिकाओं को सौंपती हैं (दान में संलग्न होने के लिए सभी समान नहीं)।

रिपोर्ट अवलोकन

1. हम DevOps है। चलो सभी परीक्षकों को आग लगाते हैं - बारूक सदोगुरस्की।

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

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



2. एक परियोजना को फिर से बनाने की आवश्यकता है? वहाँ आईडिया है! - अर्टेम इरशेंको।

अपनी रिपोर्ट में एर्टोम ने IntelliJ IDEA के लिए ऐक्शन प्लग-इन बनाने के बारे में बात की, जो आपको टेस्ट प्रोजेक्ट के कोड को जल्दी से बदलने में मदद करेगा।



उन्होंने मुख्य वर्गों (AnAction, PsiClass, PsiAnnotation, AnActionEvent, JavaCodeStyleManager) का स्पष्टीकरण दिया, जो प्लगिन क्रियाओं के इनपुट बिंदु हैं।

निम्नलिखित कार्यों को हल करने के तरीके पर विचार:

क) परियोजना पर क्या स्वचालित है और क्या नहीं है। जीरा के साथ ऑटो सिंक।


एनोटेशन पाठ के अनुसार, @DisplayName जीरा गया, आवश्यक टिकट प्राप्त किए और @TmsLink का उपयोग करके सभी आवश्यक कनेक्शन नीचे रख दिए।

b) जीरा संदर्भ से @ स्वचालित रूप से परिशिष्ट।


पसंदीदा , पुनःप्राप्त टिकट में कुछ लेबल हैं। हम परीक्षण के लिए जाते हैं, @TmsLink एनोटेशन हैं, हम प्लगइन का उपयोग करते हैं और हमारे पास नए @ टैग्स एनोटेशन हैं, और फिर जूनिट की मदद से हम इन टैगों पर परीक्षण चला सकते हैं।

ग) परीक्षणों में क्या जांचा गया है?


एक ऑटोटेस्ट है, वहाँ कदम हैं, हम निर्यात करते हैं और हमारे पास परीक्षणों में कदम हैं। वीडियो में भी दो परीक्षणों के लिए एक उदाहरण है।

एर्टोम ने यह भी प्रदर्शित किया कि एल्योर 1 से एल्योर 2 तक कैसे जल्दी से स्विच किया जाए।

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

3. जावा और रिएक्टर परियोजना? - लेकिन परीक्षणों के बारे में क्या? - किरिल मरकुशेव

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



व्यक्तिगत रूप से, मैंने प्रतिक्रियाशील प्रणालियों के परीक्षण के साथ व्यवहार नहीं किया, इसलिए मेरे लिए यह नया और दिलचस्प था।

4. जैसा कि हमने जेएस , सर्गेई दोकुचेव में मेमोरी लीक की खोज के लिए सीलेंट फ्रेमवर्क लिखा था ।

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

5. इंटरफेस के दृश्य परीक्षण की विशेषताएं - मिथुन उपकरण (एक दृश्य परीक्षण उपकरण) के प्रमुख डेवलपर एंटोन उस्मानस्की और हरमाइनी (एक अगली पीढ़ी, अधिक सामान्य-उद्देश्य वाला उपकरण जो स्क्रीनशॉट मुखर प्रदर्शन कर सकते हैं)।



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

6. सेलेनियम वेबड्राइवर में परेशानियां - एलेक्सी बरेंटसेव।

एलेक्सी ने सेलेनियम परियोजना की समस्याओं और उनकी घटना के कारणों के बारे में बात की। उन्होंने बज़ेल कलेक्टर का उपयोग करके मोनो-रिपॉजिटरी विधानसभा का विवरण साझा किया। उन्होंने तत्व दृश्यता के विषय पर छुआ (डब्लू 3 सी वेबड्राइवर मानक में कोई ऑपरेशन नहीं है जो यह जांचता है कि कोई तत्व दिखाई दे रहा है या नहीं) और बताया गया है कि फ़ंक्शन कैसे मिलता है getProperty, getDomAttriubute, getAttp भिन्न।



परेशानियों को जानने से उपयोगकर्ताओं को बग से सुविधाओं को भेद करने और उनकी परीक्षण परियोजनाओं में प्रभावी "बैसाखी" विकसित करने की अनुमति मिलेगी।

7. खरोंच से पैदा करने के लिए व्यंजनों और एक लोड परीक्षण प्रणाली के विकास - अनातोली प्लास्कोकोवस्की।

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

अनातोली ने एक टेलीग्राम चैट लोडलैंड बनाया, जिसमें लोड परीक्षण की चर्चा है, और जहां आप मदद और सलाह के लिए दस्तक दे सकते हैं।

8. डिवाइस निर्माताओं के महाकाव्य विफलताओं - वेलेंटाइन विल्सैकोम पेटुखोव।

पहले दिन कुख्यात Wylsacom की रिपोर्ट द्वारा बंद कर दिया गया था, जो जनता द्वारा अस्पष्ट रूप से माना जाता था (टेलीग्राम :) में हेइज़ेनबैग प्रतिभागियों की चैट को देखते हुए)।

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



9. ग्लोबल एसएमएस प्लेटफॉर्म - एंड्री मार्केलोव के उदाहरण का उपयोग करके टेस्टकॉनटेनर्स और जेयूनाइट 5 का उपयोग करके माइक्रो-सर्विस चिड़ियाघर का सुरुचिपूर्ण एकीकरण परीक्षण ।

लेखक ने बताया कि किस तरह से उनकी कंपनी में टेस्टऑनटेनर + जूनिट 5 + मॉकसेवर बंडल का उपयोग करके माइक्रोसेवा का परीक्षण किया जा रहा है। रिपोर्ट दिलचस्प लगी, लेकिन इस तरह की योजना बड़ी संख्या में माइक्रोसर्विसेज के लिए नहीं है। स्रोत कोड से लिंक करें



10. टेस्टर का वायुरिज़्म , या उपयोगकर्ताओं की निगरानी कैसे आपकी मदद करेगी - एंटोनिना खिसमेतदिनोवा।

एक बहुत ही दिलचस्प रिपोर्ट, हालाँकि परीक्षण की तुलना में वेब डिज़ाइन से अधिक संबंधित है। यह क्लाइंट इंटरफ़ेस डिज़ाइन करते समय बचने के लिए UX प्रथाओं और नुकसान के बारे में बात करता है।



एंटिना ने उपयोगकर्ताओं को ऐसे यूआई समाधानों में बटन को अक्षम करने, लोडर, टूलटिप्स, परिचित घटकों आदि का उपयोग करते समय मुख्य त्रुटियों की पहचान की।

यह वास्तविक परियोजनाओं से सहज ज्ञान युक्त उदाहरणों के साथ रिपोर्ट के ग्राफिक डिजाइन को भी ध्यान देने योग्य है (जैसा कि यूएक्स के बारे में रिपोर्ट में बताया गया है)।

11. बाहरी निर्भरता के साथ परीक्षण प्रणाली: समस्याएं, समाधान, माउंटबैंक - एंड्री ग्लेज़कोव।

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



मुख्य लाभ:

• माउंटबैंक - टीसीपी स्तर पर काम करता है;
• जावास्क्रिप्ट इंजेक्शन;
• विश्वसनीयता और बॉक्स से बाहर गति;
• उत्कृष्ट प्रलेखन;
• docker कंटेनरीकरण समर्थन।

उपकरण सीमाओं की पहचान:

• डेटा भंडारण के साथ बाहरी सिस्टम;
• WebSocket - समर्थित नहीं;
• लोड परीक्षण (> 150 आरपीएस), लेकिन आप एक बैलेंसर का उपयोग कर सकते हैं।

12. मोबाइल एप्लिकेशन की एंड-टू-एंड टेस्ट क्यों प्रोफाइल करें - व्यस्कलेव फ्रोलोव।

व्याचेस्लाव ने अपनी रिपोर्ट में, बेथ में ऑटोटेस्ट्स की स्थिति के बारे में बात की, अर्थात्, उन्होंने 1,500 मोबाइल यूआई परीक्षणों को समानांतर करने की समस्या को कैसे हल किया, जो एक सिम्युलेटर पर चलने के लिए 30 मशीन घंटे लगते हैं। नतीजतन, वे 30 मिनट के परिणाम को प्राप्त करने में कामयाब रहे, जिससे उन्हें प्रति दिन 80 हजार परीक्षण चलाने की अनुमति मिली। सत्ता में एक रैखिक वृद्धि के अलावा, सिम्युलेटर को पुनरारंभ करने के बजाय एप्लिकेशन कैश को साफ़ करने के लिए अनुकूलन लागू किया गया था। रिपोर्ट में प्रोफाइलर्स का भी उल्लेख किया गया था, और परीक्षण में अड़चनों के विशेष मामलों का पता लगाने के लिए उनका उपयोग कैसे किया गया था: उदाहरण के लिए, ios 11.0 में long_press () विधि 5 सेकंड के लिए चली, और अनुकूलन के बाद यह एक सेकंड में चलने लगी, या http-हेडर की मदद से कैसे -alive "आप कनेक्शन को फिर से स्थापित करने से बच सकते हैं, जिससे एक ही बार में सभी परीक्षणों को तेज किया जा सकता है। लेखक ने यह भी बताया कि फ्लेमग्राफ और फ्लेमचार्ट टूल्स का उपयोग करके प्रोफाइलर परिणामों को कैसे प्रदर्शित किया जाए।



13. इकाई परीक्षण: सिद्धांत से अभ्यास तक - वादिम पुश्तैव।

लेखक UnitTests के विकास में अपने अनुभव को साझा करता है। रिपोर्ट में तीन भाग शामिल थे।

1. हम UT से क्या चाहते हैं → रिग्रेशन (कोड बदला गया), आर्किटेक्चर पर प्रभाव (जब डेवलपर्स परीक्षण लिखते हैं, तो कोड बेहतर हो जाता है), अंडरस्टैंडिंग (विरासत कोड से निपटने के लिए);
2. सिद्धांत → वादिम याद करते हैं कि सिद्धांत अभ्यास की तरह अच्छा नहीं है। "परीक्षण का इंटरफ़ेस, कार्यान्वयन नहीं," के सिद्धांत को अस्वीकार कर दिया क्योंकि कार्यान्वयन में बहुत सारे तर्क हो सकते हैं। इसके अलावा, सिद्धांत "इकाई परीक्षण एक परीक्षण तंत्र नहीं है।" वह इसे एक तरह की वास्तु तकनीक, शक्तिशाली और बहुत उपयोगी मानता है, लेकिन यह कोड की जाँच और शुद्धता के लिए एक तंत्र नहीं है।
3. कार्यान्वयन → तकनीकी तरीकों के बारे में एक कहानी जो लेखक काम में उपयोग करता है (प्रत्येक वर्ग के लिए एक परीक्षण वर्ग, अपने स्वयं के गेमर्स का निर्माण, यदि आवश्यक हो, तो बाहरी निर्भरता का उपयोग, आदि)।

14. स्प्रिंग बूट टेस्ट के साथ परीक्षण और रोना - किरील टोल्चेचेव

सिरिल ने हमें IoC, DI और स्प्रिंग की दुनिया में लौटने का फैसला किया और बताया कि JUnit 5 और स्प्रिंगबूट का उपयोग करके यूनिट और घटक परीक्षण कैसे लिखें।



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

15. हम मोबाइल ऑटोटेस्ट पंप करते हैं - एकाटेरिना बेटेवा।

रिपोर्ट में, लेखक ने iOS एप्लिकेशन को स्वचालित करने के लिए XCTest टूल की जांच की। अन्य परियोजनाओं पर इस टूल को डुप्लिकेट करना असुविधाजनक था।



अर्थात्, निम्नलिखित नुकसानों की पहचान की गई:

• स्टार्टअप सेटिंग्स को पढ़ने के लिए कठिन;
• असेंबलियों को कॉन्फ़िगर करना मुश्किल;
• विभिन्न सेवाओं के साथ एकीकृत करना मुश्किल है;
• स्क्रीनशॉट का प्रबंधन करने के लिए असुविधाजनक;
• परीक्षण पुनरारंभ को कॉन्फ़िगर करने में असुविधाजनक।

इसके बाद, कैथरीन ने ओपन-सोर्स फास्टलेन ढांचे के बारे में बात की, जिसने उनकी समस्याओं को हल किया।

परिणाम

सामान्य तौर पर, मुझे सम्मेलन पसंद आया। भावनाओं के आरोप और ब्याज के सवालों के जवाब मिले। BoF सत्र में, अधिकांश प्रतिभागियों ने अपने "मास्क" उतार दिए और BoF विषयों के ढांचे के भीतर चर्चाओं को गर्म कर दिया। कॉफी ब्रेक और डिनर एकदम सही थे, खाने के लिए हमेशा कुछ न कुछ होता था। मैं इस घटना के संगठन पर भी ध्यान देना चाहता हूं - JUG.RU टीम हर बार हाइजेनबग को बेहतर और बेहतर बनाती है। अंत में - सम्मेलनों पर जाएं, प्राप्त ज्ञान को साझा करें और अपने कौशल में सुधार करें!

पुनश्च: मैं लेख की तैयारी में भाग लेने के लिए और वीडियो सामग्री के लिए आर्टेम इरशेंको के लिए अलेक्सी रुम्यंटसे का आभार व्यक्त करता हूं।