😤 👉 📯 मास्को यात्रा प्रतिभागियों की आंखों के माध्यम से हैक 🚸 ➿ 🎰

मॉस्को की यात्रा में एयरोक्लब आईटी टीम हैक

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

आवेदन करते समय, 10 प्रस्तावित कार्यों (पटरियों) में से एक को चुनना आवश्यक था। ये मेगाफ़ॉन, फ़ेसबुक, पैनोरमा 360, एमटीएस स्टार्टअप हब, एयरोएक्सप्रेस, पुश्किन संग्रहालय, ज़ारित्सिनो पार्क, डिस्कवर मॉस्को, सिटी ऑफ़ डिस्कवरेज़, और रसपास जैसी ऐसी प्रसिद्ध कंपनियों के मामले थे।

हमने एक साथ दो टीमों की भागीदारी के लिए आवेदन किया: "टीम" ट्रैक "एयरोएक्सप्रेस" में , और " ज़ारित्सिनो" में "नए क्षितिज " । पहले एक को चुना गया था क्योंकि यह हमारी कंपनी (बी 2 बी सॉफ्टवेयर समाधान) की गतिविधि के क्षेत्र के करीब है, और जीत के मामले में हम सहयोग और विकास जारी रख सकते हैं। दूसरा - जो लोग रोजमर्रा के कामों से भागना चाहते थे और कुछ नया करने की कोशिश कर रहे थे।

घटना की सामान्य बातचीत में, उन्होंने कहा कि 1241 आवेदन जमा किए गए थे (टीम और व्यक्तिगत दोनों), और, जैसा कि आप पहले से ही अनुमान लगा सकते हैं, हमने चयन पारित कर दिया! और हमारी दोनों टीमें!
हैकाथॉन में भाग लेने के लिए केवल एक चीज बची थी।

आयोजित हैकथॉन

साइट पर सब कुछ सामान्य था: पंजीकरण, स्नैक क्षेत्र, टीम संख्याओं के साथ टेबल।
9:30 बजे एक छोटा उद्घाटन हुआ: आयोजकों के कुछ शब्द, हैकाथॉन की शुरुआत, और काम शुरू हुआ। इसके बाद, हम टीम 73 टीम के प्रतिभागियों की ओर से बात करेंगे, जिन्होंने एयरोएक्सप्रेस से कार्य लिया था।

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

फेसला

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

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

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

फ़्रंट एंड

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

नतीजतन, हमें इस तरह का एक दृश्य मिला:

हमने एरोएक्सप्रेस के रंगों को रखते हुए उपस्थिति को आधुनिक, स्टाइलिश बनाने की कोशिश की।

यहाँ हमने निम्न कार्यक्षमता लागू की है:

TIN द्वारा कंपनी का नाम खोजें
प्रति माह टिकट बिक्री की अनुमानित मात्रा के संकेत के साथ एक कंपनी और एक संपर्क व्यक्ति का पंजीकरण।
कंपनी कर्मचारी प्राधिकरण
टिकट का आदेश
आने वाली यात्राओं की संख्या
आदेशों का इतिहास
एयरोस्पेस प्रबंधक का व्यक्तिगत खाता

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

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

बैकएंड

हमारे दोनों बैक डेवलपर्स अनुभवी शार्पिस्ट हैं (वे C # में लिखते हैं), इसलिए बैक भी .net कोर पर आधारित है। संस्करण 2.1 को चुना गया था, क्योंकि इस पर एप्लिकेशन निश्चित रूप से बैकअप होस्टिंग पर बढ़ते हैं, और हैकथॉन पर प्रयोग करना खतरनाक है - आप समय खो सकते हैं और समाधान के बिना छोड़ सकते हैं। हमें लाठी और DI के साथ सामान्य वेब-एपी मिला।
यहां हमने "सामने" के लिए आवश्यक सब कुछ किया है:

TIN द्वारा कंपनी की जानकारी खोजें
कंपनी और उसके संपर्क व्यक्ति का पंजीकरण
पासवर्ड प्रमाणीकरण
बियरर टोकन प्राधिकरण
उपयोगकर्ता जानकारी प्राप्त करना
वर्तमान उपयोगकर्ता के कंपनी कर्मचारियों की सूची प्राप्त करना
आदेश बनाएँ
ऑर्डर बनाने के बाद डाक से टिकट भेजना
अनुरोध किए गए उपयोगकर्ता को मेल द्वारा टिकट भेजना (बाहरी एकीकरण के लिए)
सभी कंपनी टिकटों के बारे में जानकारी प्राप्त करना
लिस्टिंग के आदेश
सूचीबद्ध कंपनियों की सूची बनाना

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

आवाज सहायक कौशल

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

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

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

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

हर कीमत पर एक उपयोगकर्ता नाम को परिष्कृत करना

किसी भी कीमत पर उपयोगकर्ता नाम का स्पष्टीकरण

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

प्रशिक्षण वाक्यांशों को चिह्नित किया

आशय के पैरामीटर

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

स्पष्ट वाक्यांश

सामान्य उत्तर

तब सब कुछ सरल होता है: यदि कार्रवाई नाम प्राप्त होता है और DF प्रतिक्रिया के सभी आवश्यक पैरामीटर होते हैं, तो हम इस क्रिया को करते हैं और उपयोगकर्ता को प्रतिक्रिया देते हैं। यदि नहीं, तो स्पष्टीकरण पाठ भेजें।

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

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

और यहां हमने देखा कि ऐलिस से अनुरोध में नाम अलग-अलग क्षेत्रों में सामान्यीकृत और दर्ज किए गए हैं!

मान्यता प्राप्त नाम

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

नतीजतन, हमें ऐसी श्रृंखला मिली:

क्वेरी आरेख

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

काम के दौरान एक तकनीकी कमीशन भी लिया गया: प्रत्येक टीम को अपनी रिपॉजिटरी तक पहुंच प्रदान करनी थी, और प्रति घंटे कम से कम एक बार उनमें "कमिट" करना था। इसके अलावा, कभी-कभी आयोग के प्रतिनिधि हमारे पास आए और विकसित किए जा रहे समाधान पर चर्चा की। वैसे, आप हैकाथॉन की उनकी छाप यहां पा सकते हैं ।

विजेताओं

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

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

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

प्रतिभागी स्वयं ITMO के बजट विभाग के छात्र हैं। जैसा कि लोगों ने एक व्यक्तिगत बातचीत में कहा, वे हमेशा साइट पर थे, रात में वे कहीं भी नहीं जाते थे, और 30 में से लगभग 26 घंटे (निश्चित रूप से) के लिए "प्रतिज्ञा" की गई थी। उन्हें पहले ही हैकथॉन में भाग लेने का अनुभव था, लेकिन पहली बार पुरस्कार लिया जा रहा है।

जाँच - परिणाम

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

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

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

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

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

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

यदि आप हमारे समाधान के कार्यान्वयन के तकनीकी विवरण में रुचि रखते हैं - टिप्पणियों में लिखें, हम आपको खुशी से बताएंगे।
अलविदा मत कहो, हब पर मिलते हैं
टीम 73 टीम, एयरो क्लब आईटी

मॉस्को की यात्रा में एयरोक्लब आईटी टीम हैक

मास्को यात्रा प्रतिभागियों की आंखों के माध्यम से हैक