NGINX बाट आधुनिक अनुप्रयोगहरू विकास गर्नका लागि सिद्धान्तहरू। भाग 1

नमस्ते साथीहरू। पाठ्यक्रमको शुभारम्भको प्रत्याशामा PHP ब्याकएन्ड विकासकर्ता, परम्परागत रूपमा तपाईसँग उपयोगी सामग्रीको अनुवाद साझेदारी गर्नुहोस्।

सफ्टवेयरले अधिक र अधिक दैनिक कार्यहरू समाधान गर्दछ, जबकि अधिक जटिल हुँदै जान्छ। मार्क एन्ड्रेसनले एकपटक भनेझैं, यसले संसारलाई खपत गर्छ।

नतिजाको रूपमा, विगत केही वर्षहरूमा अनुप्रयोगहरू विकसित र डेलिभर गर्ने तरिका नाटकीय रूपमा परिवर्तन भएको छ। यी टेक्टोनिक स्केलको परिवर्तनहरू थिए जसले सिद्धान्तहरूको सेटको परिणाम दिन्छ। यी सिद्धान्तहरूले टोली निर्माण, डिजाइन, विकास, र अन्तिम प्रयोगकर्ताहरूलाई तपाइँको अनुप्रयोग डेलिभर गर्न मद्दतकारी साबित भएका छन्।

सिद्धान्तहरूलाई निम्नानुसार संक्षेप गर्न सकिन्छ: अनुप्रयोग सानो, वेब-आधारित, र विकासकर्ता-केन्द्रित वास्तुकला हुनुपर्छ। यी तीन सिद्धान्तहरूलाई दिमागमा राखेर, तपाईंले एक बलियो, अन्त-देखि-अन्त अनुप्रयोग सिर्जना गर्न सक्नुहुन्छ जुन अन्तिम प्रयोगकर्तालाई छिटो र सुरक्षित रूपमा डेलिभर गर्न सकिन्छ, र सजिलै मापनयोग्य र विस्तारयोग्य छ।

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

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

यी सिद्धान्तहरू लागू गरेर, तपाईंले आफैंलाई सफ्टवेयर विकासमा नवीनतम प्रवृत्तिहरूको फाइदा लिइरहेको पाउनुहुनेछ, सहित DevOps अनुप्रयोगहरूको विकास र डेलिभरीमा, कन्टेनरहरूको प्रयोग (उदाहरणका लागि, डकर) र कन्टेनर अर्केस्ट्रेशन फ्रेमवर्क (उदाहरणका लागि, कुबर्नेट्स), माइक्रोसर्विसेसको प्रयोग (माइक्रोसर्भिस आर्किटेक्चर सहित NGINX и नेटवर्क संचार वास्तुकला माइक्रोसेवा अनुप्रयोगहरूको लागि।

आधुनिक अनुप्रयोग के हो?

आधुनिक अनुप्रयोगहरू? आधुनिक स्ट्याक? वास्तवमा "आधुनिक" भनेको के हो?

धेरै विकासकर्ताहरूसँग आधुनिक अनुप्रयोगमा के समावेश छ भन्ने सामान्य विचार मात्र छ, त्यसैले यो अवधारणालाई स्पष्ट रूपमा परिभाषित गर्न आवश्यक छ।

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

एक आधुनिक अनुप्रयोगले अनुरोध गरिएको डाटा र सेवाहरू पहुँच गर्न API प्रदान गर्दछ। API अपरिवर्तनीय र स्थिर हुनुपर्छ, र विशेष ग्राहकबाट विशेष अनुरोधको लागि विशेष रूपमा लेखिएको हुँदैन। API HTTP(S) मा उपलब्ध छ र GUI वा CLI मा उपलब्ध सबै प्रकार्यहरूमा पहुँच प्रदान गर्दछ।

डेटा सामान्यतया स्वीकृत, अन्तरक्रियात्मक ढाँचामा उपलब्ध हुनुपर्छ जस्तै JSON। एपीआईले वस्तुहरू र सेवाहरूलाई सफा, संगठित तरिकामा उजागर गर्छ, जस्तै RESTful API वा GraphQL ले राम्रो इन्टरफेस प्रदान गर्दछ।

आधुनिक अनुप्रयोगहरू आधुनिक स्ट्याकमा निर्मित छन्, र आधुनिक स्ट्याक स्ट्याक हो जसले क्रमशः त्यस्ता अनुप्रयोगहरूलाई समर्थन गर्दछ। यो स्ट्याकले विकासकर्तालाई HTTP इन्टरफेस र स्पष्ट API अन्त्यबिन्दुहरूसँग सजिलैसँग एउटा अनुप्रयोग सिर्जना गर्न अनुमति दिन्छ। छनौट गरिएको दृष्टिकोणले तपाईको एप्लिकेसनलाई JSON ढाँचामा डाटा सजिलै प्राप्त गर्न र पठाउन अनुमति दिनेछ। अर्को शब्दमा, आधुनिक स्ट्याकले बाह्र-फ्याक्टर अनुप्रयोगको तत्वहरूसँग मेल खान्छ। सूक्ष्म सेवाहरू.

यस प्रकारको स्ट्याकको लोकप्रिय संस्करणहरू आधारित छन् Java, अजगर, नोड, रूबी, PHP и Go। माइक्रोसर्भिस आर्किटेक्चर NGINX उल्लेखित प्रत्येक भाषामा लागू गरिएको आधुनिक स्ट्याकको उदाहरण प्रतिनिधित्व गर्दछ।

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

सिद्धान्तहरू

अब हामीसँग आधुनिक अनुप्रयोग र आधुनिक स्ट्याक के हो भन्ने सामान्य बुझाइ छ, यो वास्तुकला र विकास सिद्धान्तहरूमा डुब्ने समय हो जसले तपाईंलाई आधुनिक अनुप्रयोगको विकास, कार्यान्वयन र मर्मतमा राम्रोसँग सेवा दिनेछ।

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

दोस्रो सिद्धान्त यो हो कि हामीले विकासकर्ताहरूलाई उनीहरूले विकास गरिरहेका सुविधाहरूमा ध्यान केन्द्रित गर्न मद्दत गरेर उनीहरूलाई पूर्वाधार र कार्यान्वयनको क्रममा CI/CD चिन्ताहरूबाट मुक्त गर्दै उत्पादकत्व बढाउन सक्छौं। त्यसैले, संक्षेपमा, हाम्रो दृष्टिकोण विकासकर्ताहरूमा केन्द्रित.

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

यदि तपाईंले एप्लिकेसन डिजाइन र कार्यान्वयन गर्दा यी सिद्धान्तहरूलाई ध्यानमा राख्नुभयो भने, तपाईंले आफ्नो उत्पादनको विकास र डेलिभरीमा निर्विवाद फाइदा पाउनुहुनेछ।

यी तीन सिद्धान्तहरूलाई थप विस्तारमा हेरौं।

सानोता सिद्धान्त

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

निम्न कारणहरूको लागि आवेदनहरू विघटित हुन्छन्:

• विकासकर्ताहरूमा कम संज्ञानात्मक भार;
• परीक्षण को गति र सरलीकरण;
• अनुप्रयोगमा परिवर्तनहरूको द्रुत वितरण।

विकासकर्ताहरूमा संज्ञानात्मक भार कम गर्ने धेरै तरिकाहरू छन्, र यो जहाँ सानोताको सिद्धान्त खेलमा आउँछ।

त्यसैले यहाँ संज्ञानात्मक लोड कम गर्न तीन तरिकाहरू छन्:

1. नयाँ सुविधा विकास गर्दा उनीहरूले विचार गर्नुपर्ने समय सीमा घटाउनुहोस् - समय सीमा जति छोटो हुन्छ, संज्ञानात्मक भार त्यति नै कम हुन्छ।
2. कोडको मात्रा घटाउनुहोस् जसमा एक-पटक काम गरिन्छ - कम कोड - कम लोड।
3. एप्लिकेसनमा वृद्धिशील परिवर्तनहरू गर्ने प्रक्रियालाई सरल बनाउनुहोस्।

विकास समय सीमा कम गर्दै

विधिविधानका दिनहरूमा फर्कौं waterfall विकास प्रक्रियाको लागि मानक थियो, र अनुप्रयोग विकास वा अद्यावधिक गर्नको लागि छ महिनादेखि दुई वर्षको समय सीमा सामान्य अभ्यास थियो। सामान्यतया, इन्जिनियरहरूले पहिले उत्पादन आवश्यकताहरू (PRD), प्रणाली सन्दर्भ कागजात (SRD), आर्किटेक्चर ब्लुप्रिन्ट जस्ता सान्दर्भिक कागजातहरू पढ्छन्, र यी सबै चीजहरूलाई एक संज्ञानात्मक मोडेलमा संयोजन गर्न थाल्छन्, जसको अनुसार तिनीहरूले कोड गरे। आवश्यकताहरू र फलस्वरूप, वास्तुकला परिवर्तन भएको रूपमा, संज्ञानात्मक मोडेलमा अद्यावधिकहरूको बारेमा सम्पूर्ण टोलीलाई सूचित गर्न गम्भीर प्रयास गर्नुपर्‍यो। यस्तो दृष्टिकोण, नराम्रो मा, केवल काम पक्षाघात गर्न सक्छ।

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

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

पद्धतिमा agile अन्तिम अनुप्रयोग मूल अवधारणाको अलिकति परिमार्जित संस्करण हुने अपेक्षा गरिएको छ, त्यसैले विकासको अन्तिम बिन्दु अनिवार्य रूपमा अस्पष्ट छ। प्रत्येक विशिष्ट स्प्रिन्टको नतिजा मात्र स्पष्ट र सटीक हुन सक्छ।

साना कोडबेसहरू

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

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

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

अन्य सेवाहरूसँगको अन्तरक्रिया सामान्यतया केही प्रयोगकर्ता सेवाहरू र केही प्रदायक सेवाहरूमा सीमित हुन्छ जसले सरल र सफा API कलहरू प्रयोग गर्दछ, जस्तै REST प्रयोग गरेर। यसको मतलब इन्जिनियरमा संज्ञानात्मक भार गम्भीर रूपमा कम भएको छ। सबैभन्दा ठूलो चुनौती सेवा अन्तर्क्रिया मोडेल र कसरी लेनदेन जस्ता चीजहरू बहुविध सेवाहरूमा हुन्छ बुझ्नु हो। फलस्वरूप, माइक्रोसेवाहरूको प्रयोगले कोडको मात्रा घटाएर, स्पष्ट सेवा सीमाहरू परिभाषित गरेर, र प्रयोगकर्ता र प्रदायकहरू बीचको सम्बन्धको बुझाइ प्रदान गरेर संज्ञानात्मक भार घटाउँछ।

साना वृद्धिशील परिवर्तनहरू

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

कोडको ठूला भागहरू पुन: लेख्दा, कहिलेकाहीँ परिवर्तनहरू छिटो डेलिभर गर्न सम्भव छैन किनभने अन्य प्रणाली निर्भरताहरू खेलमा आउँछन्। परिवर्तनहरूको प्रवाह नियन्त्रण गर्नको लागि, तपाईंले सुविधा लुकाउने प्रयोग गर्न सक्नुहुन्छ। सिद्धान्तमा, यसको मतलब कार्यक्षमता उत्पादनमा छ, तर यो वातावरण चर सेटिङहरू (env-var) वा केही अन्य कन्फिगरेसन संयन्त्र प्रयोग गरेर उपलब्ध छैन। यदि कोडले सबै गुणस्तर नियन्त्रण प्रक्रियाहरू पार गरेको छ भने, त्यसपछि यो सुप्त अवस्थामा उत्पादनमा समाप्त हुन सक्छ। यद्यपि, यो रणनीतिले मात्र काम गर्दछ यदि सुविधा अन्ततः सक्षम छ। अन्यथा, यसले कोडलाई मात्र अव्यवस्थित गर्नेछ र एक संज्ञानात्मक भार थप्नेछ जुन विकासकर्ताले उत्पादक हुनको लागि सामना गर्नुपर्नेछ। परिवर्तन व्यवस्थापन र वृद्धिशील परिवर्तनहरूले विकासकर्ताहरूको संज्ञानात्मक भारलाई किफायती स्तरमा राख्न मद्दत गर्दछ।

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

1. विधि प्रयोग गर्नुहोस् agileसमय सीमा सीमित गर्न जसमा टोलीले मुख्य सुविधाहरूमा ध्यान केन्द्रित गर्नुपर्छ।
2. आफ्नो आवेदन धेरै माइक्रोसेवाहरूको रूपमा लागू गर्नुहोस्। यसले कार्यान्वयन गर्न सकिने सुविधाहरूको संख्यालाई सीमित गर्नेछ र काममा संज्ञानात्मक भार राख्ने सीमाहरूलाई सुदृढ पार्नेछ।
3. ठूला र अनावश्यक भन्दा बढ्दो परिवर्तनहरूलाई प्राथमिकता दिनुहोस्, कोडका साना टुक्राहरू परिवर्तन गर्नुहोस्। परिवर्तनहरू लागू गर्नको लागि लुकाउने सुविधा प्रयोग गर्नुहोस् यदि तिनीहरू थपिए पछि तुरुन्तै देखिने छैनन्।

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

पहिलो भागको अन्त्य।

चाँडै हामी अनुवादको दोस्रो भाग प्रकाशित गर्नेछौं, र अब हामी तपाईंको टिप्पणीहरूको लागि पर्खिरहेका छौं र तपाईंलाई आमन्त्रित गर्दछौं। खुल्ला दिन, जुन आज 20.00 बजे हुनेछ।

स्रोत: www.habr.com