खेल और रेल के बारे में दो कार्यों में एक नाटक

इस साल हमने RailsRumble में भाग लेने का फैसला किया - रेल डेवलपर्स के लिए एक प्रतियोगिता, जहां टीमों को 48 घंटों में एक महान विचार के साथ पूरी तरह से काम करने वाली वेबसाइट प्रदान करनी चाहिए। मैं इस प्रतियोगिता में भाग लेने की धारणा के साथ साझा करना चाहूंगा।

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

नीचे दो कृत्यों में एक छोटा नाटक है, जिसमें पाँच पात्र और मध्यांतर हैं।

शाखा एक

प्रस्तावना

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

आउट पेशेंट का काम

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

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

माँ, माँ, मैं क्या करूँगा

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

एक दर्जन "नहीं" ने हमें कुछ वसा "हां" प्रदान किया: टीम और खिलाड़ी द्वारा खोज, आधिकारिक उपयोगकर्ता खातों और हैशटैग द्वारा पोस्ट, थोड़ा आँकड़े। हमने स्थैतिक जानकारी एकत्र की और डिजाइन पर काम करना शुरू किया।
एक दिन बिताया।

यहां मछलियों को लपेटा गया था

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


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

विराम

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

अंतिम शाखा

भाषण तकनीक

तकनीक के मामले में, हम शीर्ष पर होना चाहते थे। ले लिया:
रूबी ऑन रेल 4 ,
nginx + unicorn + capistrano
Postgres + redis
फेय
कॉफ़ीस्क्रिप्ट , ember.js

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

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

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

रेडिस ने मैसेज आईडी द्वारा कैश का आयोजन किया। SortedSet का उपयोग किया गया था: इस तथ्य के कारण कि ऐड और चेक ऑपरेशन में लॉग (n) जटिलता है, हमने इसके लिए प्रदर्शन नहीं खोने की योजना बनाई। प्राथमिकता पैरामीटर इसके अलावा का समय था। हम सभी आईडी रिकॉर्ड हमेशा के लिए नहीं रखना चाहते थे और इसलिए कम प्राथमिकता वाले पोस्ट हटाए गए (हमारे मामले में, यह समय का उपाय है)।

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

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

सामने, जैसा कि हमने कहा, ember.js पर। यह एक त्वरित एक-पृष्ठ अनुप्रयोग के लिए एक बढ़िया विकल्प निकला। सच है, विकासशील वेब अनुप्रयोगों की अपनी विचारधारा से थोड़ी सी भी विचलन के साथ उत्पन्न होने वाली कठिनाइयों के कारण, एक समाधान के लिए असफल खोजों के बाद, मुझे इसके लिए इंटरफ़ेस को फिर से करना पड़ा।

मैराथन

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

पर्दा

डीब्रीफिंग

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

सामने सब कुछ सही नहीं है। हमारे पास अंत तक इंटरफेस को सुधारने का समय नहीं था।

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

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

लेकिन कुल मिलाकर, हम किए गए कार्य से प्रसन्न हैं। और हम कितने सफल और दिलचस्प प्रोजेक्ट में सफल रहे हैं, यह आपके ऊपर है।

अंतभाषण

मैं रूस की सभी टीमों को शुभकामनाएं देना चाहता हूं।
यहां उन लोगों की एक सूची दी गई है, जिन्हें हमने पाया है, शायद कई और हैं।
rb.r13.railsrumble.com
octoscrum.r13.railsrumble.com
listio.us
object.r13.railsrumble.com
undev-angels.r13.railsrumble.com
talk-tree.r13.railsrumble.com
www.trackcha.com
railsrumble.com/entries/54-sevastopol-rb
plugin.r13.railsrumble.com
getbacktoreading.com
tip4commit.com