28 घंटे में एक प्रोटोटाइप दस्तावेज़ तुलना सेवा कैसे बनाएं और हैकथॉन जीतें

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

कैसे विविधता थी

44 टीमों के 208 लोग ग्रूपअप सहकर्मियों में हैकाथॉन के लिए एकत्र हुए, जो आयोजकों के लिए एक रिकॉर्ड था। टीमों का गठन कैसे किया गया, इसके बारे में विवरण Phystech.Genesis द्वारा लेख में पाया जा सकता है। प्रतिभागियों ने प्रत्येक कंपनी से तीन प्रस्तावित कार्यों में से एक दिन की तुलना में थोड़ा अधिक हल किया, जिससे आयोजन स्थल पर रात भर रहने और आयोजकों के भोजन के साथ अवसर मिला। 300,000 रूबल की पुरस्कार राशि को पटरियों के बीच समान रूप से विभाजित किया गया था। विचारों और कोडिंग उत्पन्न करने के अलावा, प्रतिभागियों को हैकथॉन में कैसे जीतना है, इस पर तीव्रता से भाग ले सकते हैं।



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

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

न्यू क्लाउड टेक्नोलॉजीज से हमारे सहयोगियों के मार्गदर्शन में, दो या अधिक संस्करणों की तुलना करते समय दस्तावेजों में परिवर्तन का विश्लेषण करने के लिए एक सुविधाजनक उपकरण (एल्गोरिथ्म, यूआई) के साथ आना आवश्यक था।

वास्तव में यह कार्य क्यों?

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

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



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

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

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

टीम के निर्णय जीतना

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

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



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

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





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

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




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

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

हैकाथॉन इंटरैक्शन पोस्ट करें

सितंबर के अंत में, विजेताओं की एक बैठक, न्यू क्लाउड टेक्नोलॉजीज के प्रतिनिधियों, जिनमें सीईओ दिमित्री कोमिसारोव, और Phechech.Genesis शामिल थे। बैठक में, उन्होंने कंपनी के कार्यों पर चर्चा की जिसमें हैकाथॉन के विजेता भाग ले सकते हैं। हम टीमों के साथ काम करने के लिए तत्पर हैं!