हमने अर्बन टेक चैलेंज हैकथॉन में बिग डेटा ट्रैक कैसे और क्यों जीता

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

तो पहले कुछ सामान्य टिप्पणियाँ।

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

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

जीतने के लिए, आपके पास कुछ होना चाहिए, किसी प्रकार का प्रतिस्पर्धात्मक लाभ: एक समान प्रोजेक्ट जो आपने अतीत में किया था, किसी विशिष्ट विषय में ज्ञान और अनुभव, या हैकथॉन की शुरुआत से पहले किया गया तैयार काम। हाँ, यह खेल नहीं है. हां, यह खर्च किए गए प्रयास के लायक नहीं हो सकता है (यहां, हर कोई खुद तय करता है कि 3 हजार के पुरस्कार के लिए रात में 100 सप्ताह तक कोडिंग करना उचित है या नहीं, पूरी टीम के बीच विभाजित है, और यहां तक ​​​​कि इसे प्राप्त न करने के जोखिम के साथ भी)। लेकिन, अक्सर, आगे बढ़ने का यही एकमात्र मौका होता है।

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

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

4. किसी कार्य का चयन करना। जैसा कि मैंने पहले ही कहा, आपके पास प्रतिस्पर्धात्मक लाभ होना चाहिए, हैकथॉन के लिए कार्य का चयन इसी के आधार पर किया जाता है। इसके आधार पर देखा कार्य सूची और उनकी जटिलता का आकलन करते हुए, हमने दो कार्यों पर निर्णय लिया: डीपीआईआईआर से नवीन उद्यमों की एक सूची और ईएफकेओ से एक चैटबॉट। DPIiR का कार्य बैकेंडर द्वारा चुना गया था, EFKO का कार्य मेरे द्वारा चुना गया था, क्योंकि नोड.जेएस और डायलॉगफ़्लो में चैटबॉट लिखने का अनुभव था। ईएफकेओ कार्य में एमएल भी शामिल था; मेरे पास एमएल में कुछ, बहुत व्यापक नहीं, अनुभव है। और समस्या की स्थितियों के अनुसार, मुझे ऐसा लगा कि एमएल टूल्स का उपयोग करके इसे हल करने की संभावना नहीं थी। यह भावना तब और मजबूत हुई जब मैं अर्बन टेक चैलेंज मीटअप में गया, जहां आयोजकों ने मुझे ईएफकेओ पर एक डेटासेट दिखाया, जहां उत्पाद लेआउट की लगभग 100 तस्वीरें (विभिन्न कोणों से ली गई) और लेआउट त्रुटियों के लगभग 20 वर्ग थे। और, साथ ही, जिन लोगों ने कार्य का आदेश दिया वे 90% की वर्गीकरण सफलता दर प्राप्त करना चाहते थे। परिणामस्वरूप, मैंने एमएल के बिना समाधान की एक प्रस्तुति तैयार की, बैकेंडर ने कैटलॉग के आधार पर एक प्रस्तुति तैयार की, और साथ में, प्रस्तुतियों को अंतिम रूप देने के बाद, हमने उन्हें अर्बन टेक चैलेंज में भेजा। इस स्तर पर पहले से ही, प्रत्येक प्रतिभागी की प्रेरणा और योगदान का स्तर सामने आ गया था। हमारे डिजाइनर ने चर्चा में भाग नहीं लिया, देर से जवाब दिया, और प्रस्तुति में अपने बारे में जानकारी भी अंतिम क्षण में भरी, सामान्य तौर पर, संदेह पैदा हुआ।

परिणामस्वरूप, हमने DPiIR से कार्य पास कर लिया, और इस बात से बिल्कुल भी परेशान नहीं थे कि हमने EFKO पास नहीं किया, क्योंकि कार्य हमें अजीब लग रहा था, इसे हल्के ढंग से कहें तो।

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

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

इसलिए, सोने के बाद, 9.00:4 बजे हम डेवोक्रेसी की छठी मंजिल पर बैठे थे। तब हमारे डिजाइनर ने अप्रत्याशित रूप से घोषणा की कि उसके पास लैपटॉप नहीं है और वह घर से काम करेगा, और हम फोन द्वारा संवाद करेंगे। यह आखिरी तिनका था. और इस तरह हम चार से तीन में बदल गये, हालाँकि हमने टीम का नाम नहीं बदला। फिर, यह हमारे लिए कोई बड़ा झटका नहीं था; मेरे पास पहले से ही पुराने प्रोजेक्ट का डिज़ाइन था। सामान्य तौर पर, पहले तो सब कुछ काफी सुचारू रूप से और योजना के अनुसार चला। हमने डेटाबेस में आयोजकों से नवीन कंपनियों का एक डेटासेट लोड किया (हमने neo4j का उपयोग करने का निर्णय लिया)। मैंने टाइपसेटिंग शुरू की, फिर नोड.जेएस लिया और फिर चीजें खराब होने लगीं। मैंने पहले कभी neo8j के साथ काम नहीं किया था, और सबसे पहले मैं इस डेटाबेस के लिए एक कार्यशील ड्राइवर की तलाश कर रहा था, फिर मुझे पता चला कि एक क्वेरी कैसे लिखनी है, और फिर मुझे यह जानकर आश्चर्य हुआ कि यह डेटाबेस, जब पूछताछ की जाती है, तो इसमें इकाइयाँ लौटाता है नोड ऑब्जेक्ट और उनके किनारों की एक सरणी का रूप। वे। जब मैंने टीआईएन द्वारा एक संगठन और उस पर मौजूद सभी डेटा का अनुरोध किया, तो एक संगठन ऑब्जेक्ट के बजाय, मुझे इस संगठन और उनके बीच संबंधों पर डेटा वाली वस्तुओं की एक लंबी श्रृंखला वापस कर दी गई। मैंने एक मैपर लिखा जो संपूर्ण सारणी से गुजरा और सभी वस्तुओं को उनके संगठन के अनुसार एक वस्तु में चिपका दिया। लेकिन युद्ध में, जब 20 हजार संगठनों के डेटाबेस का अनुरोध किया गया, तो इसे बेहद धीमी गति से, लगभग 30-30 सेकंड में निष्पादित किया गया। मैंने अनुकूलन के बारे में सोचना शुरू किया... और फिर हम समय पर रुके और MongoDB पर स्विच किया, और इसमें हमें लगभग 4 मिनट लगे। कुल मिलाकर, neo5j पर लगभग XNUMX घंटे बर्बाद हुए।

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

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

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

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

9. अंतिम. कोड समीक्षा के लिए हमें कई बार जूरी के पास बुलाए जाने के बाद, हम यह सोचते हुए कि हमने अंततः सभी मुद्दों को हल कर लिया है, बर्गर किंग में दोपहर का भोजन करने गए। वहां आयोजकों ने हमें दोबारा बुलाया, हमें जल्दी से अपना ऑर्डर पैक करके वापस जाना पड़ा।

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

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

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

स्रोत: www.habr.com